Re: Individual passwords for guest VNC servers ?

[Anthony Liguori <aliguori@us.ibm.com>]

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@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>     
>
>