From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HJJRT-0003Ti-Tq for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:05:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HJJRR-0003TW-Iu for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:05:14 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HJJRR-0003TT-Ew for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:05:13 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HJJRR-0001M2-2E for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:05:13 -0500 Date: Tue, 20 Feb 2007 01:05:09 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] QEMU: VNC Message-ID: <20070220010509.GC5172@redhat.com> References: <200702161402.23660.cwolsen@domainatlantic.com> <20070219190929.GT31525@redhat.com> <45DA2A46.1080105@bellard.org> <200702191837.39476.cwolsen@domainatlantic.com> <20070220003635.GB5172@redhat.com> <45DA44C2.6000601@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45DA44C2.6000601@codemonkey.ws> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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 -=|