From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Individual passwords for guest VNC servers ? Date: Tue, 26 Sep 2006 09:25:05 -0500 Message-ID: <45193841.2050001@us.ibm.com> References: <20060922131246.GD31773@redhat.com> <3AAA99889D105740BE010EB6D5A5A3B202A30D@paddington.ad.cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Masami Watanabe Cc: Ian Pratt , xen-devel@lists.xensource.com, "Daniel P. Berrange" List-Id: xen-devel@lists.xenproject.org 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 >> > >