Hi Anthony,
> 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.
It is a good method of thinking about security.
I understood that: make pipe, fork, specifies the fd number at exec.
However, I use xenstore for the following.
- Using xenstore is high generality in Xen.
- It is wasted to use it only for the purpose.
> Okay, I'm a bit confused by how you state things here. The VNC auth
> session looks something like this:
I apologize for confuse you by my hazy idea.
I would take back follows.
- In the RFB protocol, the password doesn't pass the network.
- The server encrypts random challenge data by the kept a password.
And, it compares it with the response that has been sent from
the client.
- The VNC client only encrypts the challenge data by user's password.
This encrypted challenge data is response data.
It is correct above.
- The server side has the password encrypted with peculiar key.
The peculiar key is kept in the VNC server.
I thought, this key need not be peculiar, and the server need not
have it.
However, it might be difficult when thinking about portability and
operationality of the password data.
> 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.
Yes, thanks.
At first, I tried the use standard DES of OpenSSL and gcrypt.
However, it did not go well and it abandoned it.
Because des.c from an existing VNC server of it was special.
Thank you for your suggestion.
Watanabe
On Tue, 26 Sep 2006 09:25:05 -0500, Anthony Liguori wrote:
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home