Re: [Xen-devel] Individual passwords for guest VNC servers ?

[Masami Watanabe <masami.watanabe@xxxxxxxxxxxxxx>]

I'm thinking of adding the following protection to VNC console.
I know it's not perfect, nonetheless, it's far better than the current
no protection situation. Please comment.

Specification:
- The same challenge-response auth scheme as standard VNC to be available
  from VNC viewer (like RealVNC).
- The vnc password of each VM is described in the VM configuration file.
  When omit the password, do not use authentification.
    ex) vnc_passwd = xxxxx
- Where "xxxxx" is an uuencoded encrypted password, that is,
  you can get this value by
  # cat ~/.vnc/passwd | uuencode -m passwd
    (needs uuencode command: sharutils package)


Watanabe.


> On Wed, Aug 16, 2006 at 07:11:53PM +0100, Daniel P. Berrange wrote:
> > The current implementation of the VNC server in qemu-dm appears to just
> > leverage whatever password the root user has set in /root/.vnc/passwd.
> > This doesn't really have very nice semantics if one migrates the domain
> > over to a different host...which may not have same VNC password file.
> 
> Ok, so looking more closly I'm wrong here. The VNC server in qemu-dm
> does not use a password at all - it sets the VNC auth protocol to None.
> 
> At the same time it binds to 0.0.0.0 - so any HVM guest running VNC
> is completely unsecured, accessible to anyone who can route to the
> Dom0 host unless you've firewalled off all the ports >= 5900 on the
> machine. This looks like a pretty serious flaw to be fixed for 3.0.3 
> 
> > Has anyone given any thought to / written any patches to enable assignment
> > of different passwords to individual guest's VNC servers. At its simplest
> > one could just allow the crypt/md5 hash of the desired password to be
> > supplied in the xm config file, or XenD SEXPR when creating a new domain
> > and pass that hash through to qemu-dm to use instead of /root/.vnc/passwd
> 
> It appears that given the way the standard VNC challenge-response auth
> scheme works there's no choice but to store the actual password - at very 
> least using some reversible encryption - we can't simply store the hash
> as one would with passwords for /etc/shadow.  There are other newer
> auth schemes defined in VNC protocol, but its not clear whether these
> have broad support amongst VNC viewer clients.
> 
> 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  -=| 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel