[Ovirt-devel] Re: virt-viewer plugin integration issues

Daniel P. Berrange berrange at redhat.com
Fri Aug 22 11:02:35 UTC 2008

On Fri, Aug 22, 2008 at 10:04:00AM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 21, 2008 at 11:43:45PM -0400, Perry N. Myers wrote:
> > Looking for some design advice from you guys.  Here's the situation.
> > 
> > We want to be able to run virt-viewer to connect to oVirt Node guests from 
> > hosts that are not part of the kerberos infrastructure.  From my looking 
> > around it seems we have the following options:
> > 
> > 1. enable digest-md5 as an auth mech and do user/pass auth and setup a
> >    simple service account just for virt-viewer (using qemu+tcp connect
> >    method)
> Don't use a special account - the user/pass auth should simply be delegated
> to the FreeIPA  LDAP server instead of using a local passwd DB.


> > Speaking of that... Alan, for your standalone Node patches we need to 
> > switch libvirt from gssapi to digest-md5 and create an account for people 
> > to use...  that account creation should be part of the Node first-boot 
> > configuration TUI probably (along with setting the root passwd).
> You shouldn't need to switch - you can run both SASL methods at once and
> it should choose the 'best' one to authenticate with, or you can force
> the choice with the URL shown above.  Setting up both is my recommendation

Ok, here's the low-down on SASL

There are many auth mechanisms, but if going over TCP we need one which
provides an SSF layer (ie session encryption). This narrows down the
choices to just 3,  GSSAPI, DIGEST-MD5 and SRP. SRP  is patented and not
in Fedora/Debian so that's ruled out too. Since we're explicitly trying
to provide a non-GSSAPI option, that leaves DIGEST-MD5

Digest MD5 is a shared secret mechanism. The password itself does not ever
travel on the wire; the client sends a token which proves it knows the
secret, this requires that the server have access to the cleartext secret
to verify. 

The way SASL checks shared secrets also uses plugins. By default it uses
the sasldb plugin, which checks against /etc/libvirt/passwd.db. Other
plugins are  ldapdb and sql. It looks like we ned to use one of these
two plugins. This 

So as a starting point in /etc/sasl2/libvirt.conf you'd need to enable
digest-md5 and set the desired plugin

   mech_list: gssapi digest-md5
   auxprop_plugin: ldapdb     (or sql)

If using the LDAP plugin the LDAP server needs to have the user passwords
available in cleartext. I'm unclear on whether FreeIPA does it this or not.
If it does then we just ned a little more magic config to tell the ldap
plugin how to connect to the LDAP server - this can be done with GSSAPI.

If FreeIPA doesn't make passwords available, we could setup a separate
table in the oVirt WUI database and maintain usernames/passwords in that

The main trouble with all ths stuff is that you are giving your users
the permission to onnect to libvirt on the hosts. This gives them the
permission todo anything with libvirt, not just the VNC port lookup.

So ultimately, the entire plan to use virt-viewer is flawed and oVirt 
WUI should talk to the libvirtd to discover the port number and put that 
in the HTML page. The VNC client then is merely concerned with auth against
the VNC server, and not libvirt. We'd still use a GTK-VNC baed VNC client,
simply not the virt-viewer one

We'd then want to write a VNC extension to use SASL, and have the VNC server
SASL plugin use the SQL backend for auth. That way we can authenticate the
VNC server connections against oVirt database table - and just store one
time passwords in that database. 

NB, SASL does have an explicit OTP plugin, but this doesn't provide  an 
SSF layer, so its not suitable. Hence why we need to use DIGEST-MD% and
have its password plugin lookup a OTP in the oVirt DB

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the ovirt-devel mailing list