WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

Hi all,

Thanks all point about security, I'll do as follows.
I thought that the point was the following two. 


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.

2. Method of Xen VNC Server receiving stored password
  By way of xenstore. However, it is necessary to consider xenstore-ls.


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. 

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