This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Masami Watanabe <masami.watanabe@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Individual passwords for guest VNC servers ?
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Fri, 22 Sep 2006 14:12:46 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 22 Sep 2006 06:13:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <JB2006092221043832.34149296@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D572606@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <JB2006092221043832.34149296@xxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Fri, Sep 22, 2006 at 09:04:38PM +0900, Masami Watanabe wrote:
> Specification:
>   - This is only for HVM domain.

No problem, looks easily adaptable for the paravirt FB code when that is
finally ready for merge.

>   - xend-config.sxp (for system-wide) and VM configuration files (for
>     VM-specific) can have a VNC password description.
>   - A HVM domain bringing up VNC console needs at least one password
>     description ether in xend-config.sxp or its VM configuration file.
>   - A VM-specific password takes effect if both system-wide and
>     VM-specific passwords exist.
>   - Password descriptions look like the following.  An empty string for
>     vncpassword means no authentication.
>         VM configuration file:  vncpasswd = 'string'
>         xend-config.sxp      : (vncpasswd   'string')
>   - A password has to be encoded in base64 format.  For example, you can
>     obtain one by executing the next command.
>         # cat ~/.vnc/passwd | uuencode -m passwd | head -2 | tail -1
> Configuration examples:
>   - No password authentication for all VNC consoles.
>         --- xend-config.sxp ---
>         (vncpasswd  '')
>         -----------------------
>   - Single common password for all VNC consoles.
>         --- xend-config.sxp ---
>         (vncpasswd 'PASSWORD')
>         -----------------------
>   - VM-specific password for vm1.
>         --- vm1 config --------
>         vncpasswd = "PASSWORD for vm1"
>         -----------------------
> Notes and request:
>  - On log file permissions.
>    Please mind logfile permissons since password are recorded in
>    xend and qemu-dm logfiles, though they are not decoded.

It seems the password is also trivially viewable by running 

 ps -axuwwf | grep qemu-dm

Sure its obfuscated, but that's easily reversable to get the actual

Passing around passwords either on the command line, or environment is a
big red flag from a security POV. Also the Xen guest & xend config files
all default to world readable. I think we should follow the Apache model
and store the passwords out-of-band from the main config. eg
   (vncpasswordfile '/etc/xen/vncpassword')

At this point it would make sense to have one password file for all guests,
and store them in format:  'vm-name:  pw-hash'

As Ian just suggested we could have command 'xm password'  for updating
these passwords (cf apache's  htpasswd command)

Now when launching qemu-dm, we can either pass the path to the password
file on its command line,   eg  -passwordfile /etc/xen/password, or 
passs the actual password to qemu-dm down a pipe (eg qemu-dm would read
the password from filehandle 3 upon startup). The latter would be my
preference, since then we could isolate the password handling stuff in
Xend, and not duplicate it in qemu-dm, and the paravirt  equivalent.

|=- 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