[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Individual passwords for guest VNC servers ?
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |