Re: [Qemu-devel] QEMU: VNC

[Daniel P. Berrange]

On Mon, Feb 19, 2007 at 06:45:54PM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
> >  
> >>On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
> >>    
> >>>On the technical side, adding OpenSSL support in the current VNC
> >>>implementation is QEMU seems easy (OpenSSL has a non blocking API which
> >>>can be used with the current callback API).
> >>>
> >>>Fabrice.
> >>>
> >>>      
> >>Good call... Let me look into that.
> >>    
> >
> >Actually OpenSSL has some potential licensing issues when combined with
> >GPL code so I'd avoid it. The GNU TLS library, however, is just as easy
> >to integrate into existing programs - I've modified a number of apps to
> >use it very successfully.  Or if you want support for all manner of
> >crypto key management hardware devices, there's also Mozilla NSS libraries.
> >All support non-blocking APIs, so aside from the extra code to do the TLS
> >handshake and key verification, there's little modification needed to
> >the main codebase - eg for GNU TLS once handshake is complete you can
> >simply  replace read()/write() calls with gnutls_read() / gnutls_write()
> >  
> 
> While this is all well and good, there is still the fundamental problem 
> of how does one associate credentials with a VM.  The actual security 
> mechanism is, IMHO, just an implementation detail.

Well there's a number of plausible options 

 - Password, but using challenge/resonse (either plain or TLS channel)
 - Simple  password (assuming a TLS encypted channel)
 - Whitelist based on client TLS certificate (common name/fingerprint)
 - Auth against PAM using same username of qemu process owner (asume TLS)

While in general I don't think it makes much sense to tie it into the 
host system auth scheme (because VM administrators don't map onto UNIX
accounts in the general case), the latter would be useful for developers
not wishing to setup dedicated auth. There's probably more suggestions,
but I reckon those would cover a pretty wide base of deployment scenarios
from individual developers to large corporate deployment.

I wouldn't really want to translate all these schemes into a 1000 command
line flags though, so the earlier point in the thread about a QEMU config
file becomes very relevant

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|