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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Masami Watanabe wrote:
> Hi all,
>
> Thanks all point about security, I'll do as follows.
> I thought that the point was the following two. 
>   
I've always been of the opinion that security is best left to other 
places in the stack.  With that in mind..
> 1. Storage place of encrypted password
>   Should I store it in /etc/xen/passwd ?
>     Or, should I wait for DB of Xen that will be released in the future?
>   In the latter case, the release time and information, I want you to
>   teach it.
>   Now, I think we have no choice but to use /etc/xen/passwd.
>   
I would say, forget about password storage entirely.  Have qemu-dm take 
an fd on the command line (this would also be an acceptable patch for 
upstream qemu too btw).  Have qemu-dm use that fd to read the password.
Then, I would just stick the password in the domain's configuration 
file.  Perhaps:
vncpassword = '...';

As an added bonus, if vncpassword is empty, xm could prompt the user for 
a password.  Then, xm passes the password as part of the configuration 
file.  It's debatable whether Xend should filter out the vncpassword 
parameter on a domain list.  I probably would just to be on the same 
side for now.
> 2. Method of Xen VNC Server receiving stored password
>   By way of xenstore. However, it is necessary to consider xenstore-ls.
>   
Xenstore is readable by too many things IMHO.  Doesn't seem like a good 
choice for something like this.
> and I think that the following is a problem. 
>
> - The key that encrypt challenge data is fixed. 
>   It is necessary to encrypt the challenge data by the same logic as the
>   standard VNC client.
>   However, there is no necessity for even managing the key as well as 
>   standard VNC Server.
>   Only the domain manager should know the key used for the DES decryption.
>   There is no necessity that is stored, and maintained on the Xent side. 
>   
Okay, I'm a bit confused by how you state things here.  The VNC auth 
session looks something like this:
Server generates a random, one-time 16 byte piece of data for the challenge.
Server sends challenge to client
Client encrypts challenge with password (null-padded to 8 bytes in length)
Client sends password to server

The key lives entirely within vnc.c within qemu-dm.  I'd just read 16 
bytes from /dev/[u]random to generate the key.
BTW, make sure you use the des.c from an existing VNC server.  There are 
a few incompatible changes between it and the standard des.c.
Regards,

Anthony Liguori

> When the domain is generated, the domain manager only has input the key.
> Xen preserves only the data encrypted with the key that only the manager
> knows.
> When the domain is generated, Xen inputs the key that only the manager
> knows. And, the key is passed to xend and qemu-dm.
>
>
> As soon as the above-mentioned decision is made, I will think about
> specification.
>
>
> Watanabe
>
>
> On Fri, 22 Sep 2006 14:54:24 +0100, Ian Pratt wrote:
>   
> > > 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'
> > >       
> > The new life cycle management stuff in post 3.0.3 xend changes this
> > quite a bit as a config file is only used when initially creating a VM,
> > and then information about it gets stored in xend's database. The
> > current password associated with a VM would be one of the parameters
> > stored in the database, and should be updated using 'xm vnc-password' or
> > shuch like. 
> >
> >     
> > > 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.
> > >       
> > I wouldn't rely on qemu-dm staying in dom0. I think the information
> > should be passed transiently via xenstore.
> >
> > Thanks,
> > Ian 
> >
> >     
> > > 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  -
> >     
> > > =|
> > >
> > > _______________________________________________
> > > 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
> >     
>   

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