Individual passwords for guest VNC servers ?

Individual passwords for guest VNC servers ?

[Daniel P. Berrange]

The current implementation of the VNC server in qemu-dm appears to just
leverage whatever password the root user has set in /root/.vnc/passwd.
This doesn't really have very nice semantics if one migrates the domain
over to a different host...which may not have same VNC password file.
It also doesn't allow for delegating access to individuale guest VNC
console to differeing sets of users since all guests share same password
for access.

Has anyone given any thought to / written any patches to enable assignment
of different passwords to individual guest's VNC servers. At its simplest
one could just allow the crypt/md5 hash of the desired password to be
supplied in the xm config file, or XenD SEXPR when creating a new domain
and pass that hash through to qemu-dm to use instead of /root/.vnc/passwd

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  -=| 

Re: Individual passwords for guest VNC servers ?

[Daniel P. Berrange]

On Wed, Aug 16, 2006 at 07:11:53PM +0100, Daniel P. Berrange wrote:
> The current implementation of the VNC server in qemu-dm appears to just
> leverage whatever password the root user has set in /root/.vnc/passwd.
> This doesn't really have very nice semantics if one migrates the domain
> over to a different host...which may not have same VNC password file.

Ok, so looking more closly I'm wrong here. The VNC server in qemu-dm
does not use a password at all - it sets the VNC auth protocol to None.

At the same time it binds to 0.0.0.0 - so any HVM guest running VNC
is completely unsecured, accessible to anyone who can route to the
Dom0 host unless you've firewalled off all the ports >= 5900 on the
machine. This looks like a pretty serious flaw to be fixed for 3.0.3 

> Has anyone given any thought to / written any patches to enable assignment
> of different passwords to individual guest's VNC servers. At its simplest
> one could just allow the crypt/md5 hash of the desired password to be
> supplied in the xm config file, or XenD SEXPR when creating a new domain
> and pass that hash through to qemu-dm to use instead of /root/.vnc/passwd

It appears that given the way the standard VNC challenge-response auth
scheme works there's no choice but to store the actual password - at very 
least using some reversible encryption - we can't simply store the hash
as one would with passwords for /etc/shadow.  There are other newer
auth schemes defined in VNC protocol, but its not clear whether these
have broad support amongst VNC viewer clients.

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  -=| 

Re: Individual passwords for guest VNC servers ?

[Daniel P. Berrange]

On Sat, Aug 26, 2006 at 10:07:50PM -0400, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >least using some reversible encryption - we can't simply store the hash
> >as one would with passwords for /etc/shadow.  There are other newer
> >auth schemes defined in VNC protocol, but its not clear whether these
> >have broad support amongst VNC viewer clients.
> 
> I'm of the opinion that we should just choose a set of supported 
> clients.  Much to my surprise, most clients don't even support what's 
> defined in the RFB spec--let alone all the extension :-/  Even the more 
> popular ones...  The 8 bit depths are particularly annoying as it seems 
> that no one pays attention to the pixel format :-(

Ahhhh - this 8-bit pixel format thing you talk about could explain why
I see strange colour shifts on the console for HVM domains ! Guess I'll
have to double check this stuff in the virt-manager VNC protocol code.
My normal Linux desktop RealVNC client shows a different colour-shift
again...

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  -=| 

Re: Individual passwords for guest VNC servers ?

[Masami Watanabe]

I'm thinking of adding the following protection to VNC console.
I know it's not perfect, nonetheless, it's far better than the current
no protection situation. Please comment.

Specification:
- The same challenge-response auth scheme as standard VNC to be available
  from VNC viewer (like RealVNC).
- The vnc password of each VM is described in the VM configuration file.
  When omit the password, do not use authentification.
    ex) vnc_passwd = xxxxx
- Where "xxxxx" is an uuencoded encrypted password, that is,
  you can get this value by
  # cat ~/.vnc/passwd | uuencode -m passwd
    (needs uuencode command: sharutils package)


Watanabe.


> On Wed, Aug 16, 2006 at 07:11:53PM +0100, Daniel P. Berrange wrote:
> > The current implementation of the VNC server in qemu-dm appears to just
> > leverage whatever password the root user has set in /root/.vnc/passwd.
> > This doesn't really have very nice semantics if one migrates the domain
> > over to a different host...which may not have same VNC password file.
> 
> Ok, so looking more closly I'm wrong here. The VNC server in qemu-dm
> does not use a password at all - it sets the VNC auth protocol to None.
> 
> At the same time it binds to 0.0.0.0 - so any HVM guest running VNC
> is completely unsecured, accessible to anyone who can route to the
> Dom0 host unless you've firewalled off all the ports >= 5900 on the
> machine. This looks like a pretty serious flaw to be fixed for 3.0.3 
> 
> > Has anyone given any thought to / written any patches to enable assignment
> > of different passwords to individual guest's VNC servers. At its simplest
> > one could just allow the crypt/md5 hash of the desired password to be
> > supplied in the xm config file, or XenD SEXPR when creating a new domain
> > and pass that hash through to qemu-dm to use instead of /root/.vnc/passwd
> 
> It appears that given the way the standard VNC challenge-response auth
> scheme works there's no choice but to store the actual password - at very 
> least using some reversible encryption - we can't simply store the hash
> as one would with passwords for /etc/shadow.  There are other newer
> auth schemes defined in VNC protocol, but its not clear whether these
> have broad support amongst VNC viewer clients.
> 
> 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

Re: Individual passwords for guest VNC servers ?

[Daniel P. Berrange]

On Thu, Aug 31, 2006 at 10:23:56AM +0900, Masami Watanabe wrote:
> I'm thinking of adding the following protection to VNC console.
> I know it's not perfect, nonetheless, it's far better than the current
> no protection situation. Please comment.
> 
> Specification:
> - The same challenge-response auth scheme as standard VNC to be available
>   from VNC viewer (like RealVNC).

Yeah, looking at the various clients, challenge-response is the only one
we can really rely on being present - in fact its the only one supported
by Fedora VNC client (RealVNC IIRC?) at all. 

> - The vnc password of each VM is described in the VM configuration file.
>   When omit the password, do not use authentification.
>     ex) vnc_passwd = xxxxx

I think we should be secure by default - if they omit the password then
we should either generate one - and store it in xenstore, or refuse to
activate VNC server. If we really really want to allow no passwords, then
admin could have to explicitly request it with vnc_no_password=1
in the config file - but my prefernce is still that we should flat out 
refuse to allow an empty password - in this day & day its just plain wrong.
RealVNC server for example, refuses to allow empty password.

> - Where "xxxxx" is an uuencoded encrypted password, that is,
>   you can get this value by
>   # cat ~/.vnc/passwd | uuencode -m passwd
>     (needs uuencode command: sharutils package)

Perhaps base64 would be preferable - that's a standard part of Linux
coreutils toolset, rather than an addon like uuencode is.

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  -=| 

Re: Individual passwords for guest VNC servers ?

[Masami Watanabe]

Hi Dan,

I take your point about security, I'll do as follows.
- vnc_passwd is not omissible.
- The domain cannot be created if there is no vnc_passwd.

Thanks.
Watanabe.


> On Thu, Aug 31, 2006 at 10:23:56AM +0900, Masami Watanabe wrote:
> > I'm thinking of adding the following protection to VNC console.
> > I know it's not perfect, nonetheless, it's far better than the current
> > no protection situation. Please comment.
> > 
> > Specification:
> > - The same challenge-response auth scheme as standard VNC to be available
> >   from VNC viewer (like RealVNC).
> 
> Yeah, looking at the various clients, challenge-response is the only one
> we can really rely on being present - in fact its the only one supported
> by Fedora VNC client (RealVNC IIRC?) at all. 
> 
> > - The vnc password of each VM is described in the VM configuration file.
> >   When omit the password, do not use authentification.
> >     ex) vnc_passwd = xxxxx
> 
> I think we should be secure by default - if they omit the password then
> we should either generate one - and store it in xenstore, or refuse to
> activate VNC server. If we really really want to allow no passwords, then
> admin could have to explicitly request it with vnc_no_password=1
> in the config file - but my prefernce is still that we should flat out 
> refuse to allow an empty password - in this day & day its just plain wrong.
> RealVNC server for example, refuses to allow empty password.
> 
> > - Where "xxxxx" is an uuencoded encrypted password, that is,
> >   you can get this value by
> >   # cat ~/.vnc/passwd | uuencode -m passwd
> >     (needs uuencode command: sharutils package)
> 
> Perhaps base64 would be preferable - that's a standard part of Linux
> coreutils toolset, rather than an addon like uuencode is.
> 
> 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

RE: Individual passwords for guest VNC servers ?

[Ian Pratt]

 
> I take your point about security, I'll do as follows.
> - vnc_passwd is not omissible.
> - The domain cannot be created if there is no vnc_passwd.

It would also be good to be able to specify a system-wide vnc password
in the xend-config.sxp that is overridden by individual guest configs. 

Thanks,
Ian

> > On Thu, Aug 31, 2006 at 10:23:56AM +0900, Masami Watanabe wrote:
> > > I'm thinking of adding the following protection to VNC console.
> > > I know it's not perfect, nonetheless, it's far better than the
current
> > > no protection situation. Please comment.
> > >
> > > Specification:
> > > - The same challenge-response auth scheme as standard VNC to be
> available
> > >   from VNC viewer (like RealVNC).
> >
> > Yeah, looking at the various clients, challenge-response is the only
one
> > we can really rely on being present - in fact its the only one
supported
> > by Fedora VNC client (RealVNC IIRC?) at all.
> >
> > > - The vnc password of each VM is described in the VM configuration
> file.
> > >   When omit the password, do not use authentification.
> > >     ex) vnc_passwd = xxxxx
> >
> > I think we should be secure by default - if they omit the password
then
> > we should either generate one - and store it in xenstore, or refuse
to
> > activate VNC server. If we really really want to allow no passwords,
then
> > admin could have to explicitly request it with vnc_no_password=1
> > in the config file - but my prefernce is still that we should flat
out
> > refuse to allow an empty password - in this day & day its just plain
> wrong.
> > RealVNC server for example, refuses to allow empty password.
> >
> > > - Where "xxxxx" is an uuencoded encrypted password, that is,
> > >   you can get this value by
> > >   # cat ~/.vnc/passwd | uuencode -m passwd
> > >     (needs uuencode command: sharutils package)
> >
> > Perhaps base64 would be preferable - that's a standard part of Linux
> > coreutils toolset, rather than an addon like uuencode is.
> >
> > 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

Re: Individual passwords for guest VNC servers ?

[George Dunlap]

On 8/30/06, Daniel P. Berrange <berrange@redhat.com> wrote:
> I think we should be secure by default - if they omit the password then
> we should either generate one - and store it in xenstore, or refuse to
> activate VNC server. If we really really want to allow no passwords, then
> admin could have to explicitly request it with vnc_no_password=1
> in the config file - but my prefernce is still that we should flat out
> refuse to allow an empty password - in this day & day its just plain wrong.
> RealVNC server for example, refuses to allow empty password.

IMHO this kind of "I'll make you do this for your own good" is a bug,
not a feature.

When I run a VNC server, I typically have it bound to accept
connections only from localhost, then I SSH tunnel in.  I'm the only
one using the box, so I know that no one else can log in. Being forced
to have a password when I'm already using much stronger authentication
is an annoyance and a waste of my time.

You can imagine other situations where the administrator knows that
having no password is as secure as he needs it-- on an internal
network or VPN, for instance.  Or, a single user on a local machine.
If I've got the box sitting in front of me, no one else can log in,
and I type "xm create -f hvm.cfg", why should I have to type a
password?

Having the "vnc_no_password" option is my preference; it encourages
right behavior where appropriate, but leaves the administrator the
option to make an informed decision.

 -George

RE: Individual passwords for guest VNC servers ?

[Masami Watanabe]

[-- Attachment #1: Type: text/plain, Size: 5021 bytes --]

Hi,

This patch enables password authentication to VNC console.


Specification:
  - This is only for HVM domain.
  - xend-config.sxp (for system-wide) and VM configuration files (for
    VM-specific) can have a VNC password description.
  - A HVM domain bringing up VNC console needs at least one password
    description ether in xend-config.sxp or its VM configuration file.
  - A VM-specific password takes effect if both system-wide and
    VM-specific passwords exist.
  - Password descriptions look like the following.  An empty string for
    vncpassword means no authentication.
        VM configuration file:  vncpasswd = 'string'
        xend-config.sxp      : (vncpasswd   'string')
  - A password has to be encoded in base64 format.  For example, you can
    obtain one by executing the next command.
        # cat ~/.vnc/passwd | uuencode -m passwd | head -2 | tail -1

Configuration examples:
  - No password authentication for all VNC consoles.
        --- xend-config.sxp ---
        (vncpasswd  '')
        -----------------------

  - Single common password for all VNC consoles.
        --- xend-config.sxp ---
        (vncpasswd 'PASSWORD')
        -----------------------

  - VM-specific password for vm1.
        --- vm1 config --------
        vncpasswd = "PASSWORD for vm1"
        -----------------------

Notes and request:
 - On log file permissions.
   Please mind logfile permissons since password are recorded in
   xend and qemu-dm logfiles, though they are not decoded.
 - On DES (Data Encryption Standard).
   Please check the copyright notes in d3des.h and d3des.c and the
   description that says "a portable, public domain, version of the Data
   Encryption Standard."
   I needed the DES module in standard VNC.  So I included these files
   without modification from VNC 4.1.1 source distribution for Unix
   platforms.

Other notes:
 - I tested that the following VNC clients successfully negotiated to
   the VNC console.
        VNC Viewer Free Edition 4.1.1 for X
        VNC Free Edition for Windows Version 4.1.2
        UltraVNC Win32 Viewer 1.0.2


Signed-off-by: Masami Watanabe <masami.watanabe@jp.fujitsu.com>

Best regards,
Watanabe



On Thu, 31 Aug 2006 11:45:37 +0100, Ian Pratt wrote:
> > I take your point about security, I'll do as follows.
> > - vnc_passwd is not omissible.
> > - The domain cannot be created if there is no vnc_passwd.
> 
> It would also be good to be able to specify a system-wide vnc password
> in the xend-config.sxp that is overridden by individual guest configs. 
> 
> Thanks,
> Ian
> 
> > > On Thu, Aug 31, 2006 at 10:23:56AM +0900, Masami Watanabe wrote:
> > > > I'm thinking of adding the following protection to VNC console.
> > > > I know it's not perfect, nonetheless, it's far better than the
> current
> > > > no protection situation. Please comment.
> > > >
> > > > Specification:
> > > > - The same challenge-response auth scheme as standard VNC to be
> > available
> > > >   from VNC viewer (like RealVNC).
> > >
> > > Yeah, looking at the various clients, challenge-response is the only
> one
> > > we can really rely on being present - in fact its the only one
> supported
> > > by Fedora VNC client (RealVNC IIRC?) at all.
> > >
> > > > - The vnc password of each VM is described in the VM configuration
> > file.
> > > >   When omit the password, do not use authentification.
> > > >     ex) vnc_passwd = xxxxx
> > >
> > > I think we should be secure by default - if they omit the password
> then
> > > we should either generate one - and store it in xenstore, or refuse
> to
> > > activate VNC server. If we really really want to allow no passwords,
> then
> > > admin could have to explicitly request it with vnc_no_password=1
> > > in the config file - but my prefernce is still that we should flat
> out
> > > refuse to allow an empty password - in this day & day its just plain
> > wrong.
> > > RealVNC server for example, refuses to allow empty password.
> > >
> > > > - Where "xxxxx" is an uuencoded encrypted password, that is,
> > > >   you can get this value by
> > > >   # cat ~/.vnc/passwd | uuencode -m passwd
> > > >     (needs uuencode command: sharutils package)
> > >
> > > Perhaps base64 would be preferable - that's a standard part of Linux
> > > coreutils toolset, rather than an addon like uuencode is.
> > >
> > > 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

[-- Attachment #2: vnc_auth.patch --]
[-- Type: application/octet-stream, Size: 29830 bytes --]

diff -r 515d6e7ac66c tools/examples/xend-config.sxp
--- a/tools/examples/xend-config.sxp	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/examples/xend-config.sxp	Thu Sep 21 14:44:45 2006 +0900
@@ -130,3 +130,7 @@
 
 # The tool used for initiating virtual TPM migration
 #(external-migration-tool '')
+
+# The default password for VNC console on HVM domain.
+# Empty string is no authentication.
+(vncpasswd '')
diff -r 515d6e7ac66c tools/examples/xmexample.hvm
--- a/tools/examples/xmexample.hvm	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/examples/xmexample.hvm	Thu Sep 21 14:08:48 2006 +0900
@@ -145,6 +145,11 @@ vnc=1
 #vncconsole=0
 
 #----------------------------------------------------------------------------
+# set password for domain's VNC console
+# default is depents on vncpasswd in xend-config.sxp
+vncpasswd=''
+
+#----------------------------------------------------------------------------
 # no graphics, use serial port
 #nographic=0
 
diff -r 515d6e7ac66c tools/examples/xmexample.vti
--- a/tools/examples/xmexample.vti	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/examples/xmexample.vti	Thu Sep 21 14:09:42 2006 +0900
@@ -95,6 +95,11 @@ vnc=0
 #vncconsole=0
 
 #----------------------------------------------------------------------------
+# set password for domain's VNC console
+# default is depents on vncpasswd in xend-config.sxp
+vncpasswd=''
+
+#----------------------------------------------------------------------------
 # no graphics, use serial port
 #nographic=0
 
diff -r 515d6e7ac66c tools/ioemu/Makefile.target
--- a/tools/ioemu/Makefile.target	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/ioemu/Makefile.target	Thu Sep 21 14:11:24 2006 +0900
@@ -398,6 +398,7 @@ VL_OBJS+=sdl.o
 VL_OBJS+=sdl.o
 endif
 VL_OBJS+=vnc.o
+VL_OBJS+=d3des.o
 ifdef CONFIG_COCOA
 VL_OBJS+=cocoa.o
 COCOA_LIBS=-F/System/Library/Frameworks -framework Cocoa -framework IOKit
@@ -456,6 +457,9 @@ sdl.o: sdl.c keymaps.c sdl_keysym.h
 	$(CC) $(CFLAGS) $(DEFINES) $(SDL_CFLAGS) -c -o $@ $<
 
 vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h
+	$(CC) $(CFLAGS) $(DEFINES) -c -o $@ $<
+
+d3des.o: d3des.c d3des.h
 	$(CC) $(CFLAGS) $(DEFINES) -c -o $@ $<
 
 sdlaudio.o: sdlaudio.c
diff -r 515d6e7ac66c tools/ioemu/vl.c
--- a/tools/ioemu/vl.c	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/ioemu/vl.c	Thu Sep 21 19:19:57 2006 +0900
@@ -169,6 +169,9 @@ time_t timeoffset = 0;
 
 char domain_name[1024] = { 'H','V', 'M', 'X', 'E', 'N', '-'};
 extern int domid;
+
+char vncpasswd[64];
+unsigned char challenge[AUTHCHALLENGESIZE];
 
 /***********************************************************/
 /* x86 ISA bus support */
@@ -5438,6 +5441,7 @@ enum {
     QEMU_OPTION_acpi,
     QEMU_OPTION_vncviewer,
     QEMU_OPTION_vncunused,
+    QEMU_OPTION_vncpasswd,
 };
 
 typedef struct QEMUOption {
@@ -5516,6 +5520,7 @@ const QEMUOption qemu_options[] = {
     { "vnc", HAS_ARG, QEMU_OPTION_vnc },
     { "vncviewer", 0, QEMU_OPTION_vncviewer },
     { "vncunused", 0, QEMU_OPTION_vncunused },
+    { "vncpasswd", HAS_ARG, QEMU_OPTION_vncpasswd },
     
     /* temporary options */
     { "usb", 0, QEMU_OPTION_usb },
@@ -5895,6 +5900,7 @@ int main(int argc, char **argv)
     vncunused = 0;
     kernel_filename = NULL;
     kernel_cmdline = "";
+    *vncpasswd = '\0';
 #ifndef CONFIG_DM
 #ifdef TARGET_PPC
     cdrom_index = 1;
@@ -6306,6 +6312,13 @@ int main(int argc, char **argv)
                 if (vnc_display == -1)
                     vnc_display = -2;
                 break;
+            case QEMU_OPTION_vncpasswd:
+                strcpy(vncpasswd, optarg);
+                /* prevention of ps */
+                argv[optind-1][0] = '*';
+                for (i=1; argv[optind-1][i]; i++)
+                    argv[optind-1][i] = '\0';
+                break;
             }
         }
     }
diff -r 515d6e7ac66c tools/ioemu/vl.h
--- a/tools/ioemu/vl.h	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/ioemu/vl.h	Thu Sep 21 18:39:38 2006 +0900
@@ -1219,4 +1219,7 @@ extern char domain_name[];
 
 void destroy_hvm_domain(void);
 
+/* VNC Authentication */
+#define AUTHCHALLENGESIZE 16
+
 #endif /* VL_H */
diff -r 515d6e7ac66c tools/ioemu/vnc.c
--- a/tools/ioemu/vnc.c	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/ioemu/vnc.c	Thu Sep 21 19:13:13 2006 +0900
@@ -31,6 +31,7 @@
 
 #include "vnc_keysym.h"
 #include "keymaps.c"
+#include "d3des.h"
 
 #define XK_MISCELLANY
 #define XK_LATIN1
@@ -125,6 +126,10 @@ static void vnc_update_client(void *opaq
 static void vnc_update_client(void *opaque);
 static void vnc_client_read(void *opaque);
 static void framebuffer_set_updated(VncState *vs, int x, int y, int w, int h);
+static int vnc_auth(VncState *vs);
+static int make_challenge(char *random, int size);
+static unsigned int base64value(char c1);
+static int base64decode(unsigned char *out, char *in);
 
 #if 0
 static inline void vnc_set_bit(uint32_t *d, int k)
@@ -1154,7 +1159,58 @@ static int protocol_version(VncState *vs
 	return 0;
     }
 
-    vnc_write_u32(vs, 1); /* None */
+    vnc_auth(vs);	/* Challenge-Responce authentication */
+
+    return 0;
+}
+
+static int protocol_authtype(VncState *vs, char *type, size_t len)
+{
+    return 0;
+}
+
+static unsigned char d3desObfuscationKey[] = {23,82,107,6,35,78,88,7};
+
+static int protocol_response(VncState *vs, char *client_response, size_t len)
+{
+    extern char vncpasswd[64];
+    extern unsigned char challenge[AUTHCHALLENGESIZE];
+    unsigned char cryptchallenge[AUTHCHALLENGESIZE];
+    unsigned char vmpasswd[64];
+    unsigned char vmplain[9];
+    unsigned char key[8];
+    int vmpasswdlen, i, j;
+
+    memcpy(cryptchallenge, challenge, AUTHCHALLENGESIZE);
+
+    /* base64 decode VM password */
+    vmpasswdlen = base64decode(vmpasswd, vncpasswd);
+
+    /* Get plain VM password */
+    deskey(d3desObfuscationKey, DE1);
+    des(vmpasswd, vmplain);
+    vmplain[8] = 0;
+
+    /* Calculate the sent challenge */
+    for (i=0; i<8; i++)
+	key[i] = i<vmpasswdlen ? vmplain[i] : 0;
+    deskey(key, EN0);
+    for (j = 0; j < AUTHCHALLENGESIZE; j += 8)
+	des(cryptchallenge+j, cryptchallenge+j);
+
+    /* Check the actual response */
+    if (memcmp(cryptchallenge, client_response, AUTHCHALLENGESIZE) != 0) {
+	/* password error */
+	vnc_write_u32(vs, 1);
+	vnc_write_u32(vs, 22);
+	vnc_write(vs, "Authentication failure", 22);
+	vnc_flush(vs);
+	fprintf(logfile, "VNC Password error.\n");
+	vnc_client_error(vs);
+	return 0;
+    }
+
+    vnc_write_u32(vs, 0);
     vnc_flush(vs);
 
     vnc_read_when(vs, protocol_client_init, 1);
@@ -1277,3 +1333,94 @@ int vnc_start_viewer(int port)
 	return pid;
     }
 }
+
+static int vnc_auth(VncState *vs)
+{
+    extern char vncpasswd[64];
+    extern unsigned char challenge[AUTHCHALLENGESIZE];
+
+    if (*vncpasswd == '\0') {
+	/* AuthType is None */
+	vnc_write_u32(vs, 1);
+	vnc_flush(vs);
+	vnc_read_when(vs, protocol_client_init, 1);
+    } else {
+	/* AuthType is VncAuth */
+	vnc_write_u32(vs, 2);
+	vnc_flush(vs);
+
+	/* Read AuthType */
+	vnc_read_when(vs, protocol_authtype, 1);
+
+	/* Send Challenge */
+	make_challenge(challenge, AUTHCHALLENGESIZE);
+	vnc_write(vs, challenge, AUTHCHALLENGESIZE);
+	vnc_flush(vs);
+
+	/* Read Responce */
+	vnc_read_when(vs, protocol_response, AUTHCHALLENGESIZE);
+    }
+
+    return 0;
+}
+
+static int make_challenge(char *random, int size)
+{
+    FILE *fp;
+    int readsize;
+
+    fp = fopen("/dev/random", "r");
+    if (!fp) {
+	fprintf(stderr, "make_challenge: no OS supplied /dev/random\n");
+	exit(1);
+    }
+    readsize = fread(random, size, 1, fp);
+    fclose(fp);
+
+    return 0;
+}
+
+
+const char base64char[] =
+    "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
+
+static unsigned int base64value(char c1)
+{
+    unsigned int i;
+
+    if (c1 == '=') return 0;
+    for (i=0; base64char[i]; i++) {
+	if (c1 == base64char[i]) break;
+    }
+
+    return i;
+}
+
+static int base64decode(unsigned char *out, char *in)
+{
+    int outpos = 0;		/* current position of out area */
+    int i;
+    int inlen;			/* indata length */
+
+    inlen = strlen(in);
+
+    /* base64 decode */
+    for (i=0; i<inlen; i+=4) {
+	if (in[i] == '=') break;
+	out[outpos] = (unsigned char)
+	    ( (base64value(in[i])<<2) | ((base64value(in[i+1])&0x30)>>4) );
+	out[outpos+1] = (unsigned char)
+	    ( ((base64value(in[i+1])&0x0f)<<4)|((base64value(in[i+2])&0x3c)>>2) );
+	out[outpos+2] = (unsigned char)
+	    ( ((base64value(in[i+2])&0x03)<<6) | (base64value(in[i+3])&0x3f) );
+	outpos += 3;
+    }
+
+    /* correction length */
+    if (outpos) {
+	if (in[i-1] == '=') outpos--;
+	if (in[i-2] == '=') outpos--;
+    }
+
+    return outpos;
+}
diff -r 515d6e7ac66c tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/python/xen/xend/XendDomainInfo.py	Thu Sep 21 14:47:57 2006 +0900
@@ -390,6 +390,9 @@ def parseConfig(config):
         else:
             log.warn("Ignoring malformed and deprecated config option "
                      "restart = %s", restart)
+
+    result['image'].append(
+        ['vncpasswd_default', xroot.get_vncpasswd_default()])
 
     log.debug("parseConfig: result is %s", result)
     return result
diff -r 515d6e7ac66c tools/python/xen/xend/XendRoot.py
--- a/tools/python/xen/xend/XendRoot.py	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/python/xen/xend/XendRoot.py	Thu Sep 21 14:40:15 2006 +0900
@@ -95,6 +95,8 @@ class XendRoot:
     dom0_min_mem_default = '0'
 
     dom0_vcpus_default = '0'
+
+    vncpasswd_default = '#None#'
 
     components = {}
 
@@ -272,6 +274,10 @@ class XendRoot:
     def get_console_limit(self):
         return self.get_config_int('console-limit', 1024)
 
+    def get_vncpasswd_default(self):
+        return self.get_config_value('vncpasswd',
+                                     self.vncpasswd_default)
+
 def instance():
     """Get an instance of XendRoot.
     Use this instead of the constructor.
diff -r 515d6e7ac66c tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/python/xen/xend/image.py	Thu Sep 21 17:40:02 2006 +0900
@@ -362,6 +362,20 @@ class HVMImageHandler(ImageHandler):
             vncunused = sxp.child_value(config, 'vncunused')
             if vncunused:
                 ret += ['-vncunused']
+            # get password from xend-config(if password omitted, '#None#')
+            vncpasswd_default = sxp.child_value(config,
+                                                'vncpasswd_default')
+            # get password from VM config(if password omitted, None)
+            vncpasswd = sxp.child_value(config, 'vncpasswd')
+            # password check
+            if vncpasswd is None:
+                if vncpasswd_default=='#None#':
+                    raise VmError('vncpasswd is not specified in both VMconfig and xend-config.')
+                else:
+                    vncpasswd = vncpasswd_default
+            
+            if vncpasswd!='':
+                ret = ret + ['-vncpasswd', '%s' % vncpasswd]
         return ret
 
     def createDeviceModel(self):
diff -r 515d6e7ac66c tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py	Wed Sep 20 10:59:49 2006 +0900
+++ b/tools/python/xen/xm/create.py	Thu Sep 21 14:43:40 2006 +0900
@@ -102,6 +102,10 @@ gopts.opt('console_autoconnect', short='
 gopts.opt('console_autoconnect', short='c',
           fn=set_true, default=0,
           use="Connect to the console after the domain is created.")
+
+gopts.var('vncpasswd', val='NAME',
+          fn=set_value, default=None,
+          use="Password for VNC console on HVM domain.")
 
 gopts.var('vncviewer', val='no|yes',
           fn=set_bool, default=None,
@@ -641,6 +645,7 @@ def configure_hvm(config_image, vals):
     for a in args:
         if (vals.__dict__[a]):
             config_image.append([a, vals.__dict__[a]])
+    config_image.append(['vncpasswd', vals.vncpasswd])
 
 def run_bootloader(vals, config_image):
     if not os.access(vals.bootloader, os.X_OK):
diff -r 515d6e7ac66c tools/ioemu/d3des.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/ioemu/d3des.c	Thu Sep 21 14:19:10 2006 +0900
@@ -0,0 +1,434 @@
+/*
+ * This is D3DES (V5.09) by Richard Outerbridge with the double and
+ * triple-length support removed for use in VNC.  Also the bytebit[] array
+ * has been reversed so that the most significant bit in each byte of the
+ * key is ignored, not the least significant.
+ *
+ * These changes are:
+ *  Copyright (C) 1999 AT&T Laboratories Cambridge.  All Rights Reserved.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* D3DES (V5.09) -
+ *
+ * A portable, public domain, version of the Data Encryption Standard.
+ *
+ * Written with Symantec's THINK (Lightspeed) C by Richard Outerbridge.
+ * Thanks to: Dan Hoey for his excellent Initial and Inverse permutation
+ * code;  Jim Gillogly & Phil Karn for the DES key schedule code; Dennis
+ * Ferguson, Eric Young and Dana How for comparing notes; and Ray Lau,
+ * for humouring me on.
+ *
+ * Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge.
+ * (GEnie : OUTER; CIS : [71755,204]) Graven Imagery, 1992.
+ */
+
+#include "d3des.h"
+
+static void scrunch(unsigned char *, unsigned long *);
+static void unscrun(unsigned long *, unsigned char *);
+static void desfunc(unsigned long *, unsigned long *);
+static void cookey(unsigned long *);
+
+static unsigned long KnL[32] = { 0L };
+
+static unsigned short bytebit[8]	= {
+	01, 02, 04, 010, 020, 040, 0100, 0200 };
+
+static unsigned long bigbyte[24] = {
+	0x800000L,	0x400000L,	0x200000L,	0x100000L,
+	0x80000L,	0x40000L,	0x20000L,	0x10000L,
+	0x8000L,	0x4000L,	0x2000L,	0x1000L,
+	0x800L, 	0x400L, 	0x200L, 	0x100L,
+	0x80L,		0x40L,		0x20L,		0x10L,
+	0x8L,		0x4L,		0x2L,		0x1L	};
+
+/* Use the key schedule specified in the Standard (ANSI X3.92-1981). */
+
+static unsigned char pc1[56] = {
+	56, 48, 40, 32, 24, 16,  8,	 0, 57, 49, 41, 33, 25, 17,
+	 9,  1, 58, 50, 42, 34, 26,	18, 10,  2, 59, 51, 43, 35,
+	62, 54, 46, 38, 30, 22, 14,	 6, 61, 53, 45, 37, 29, 21,
+	13,  5, 60, 52, 44, 36, 28,	20, 12,  4, 27, 19, 11,  3 };
+
+static unsigned char totrot[16] = {
+	1,2,4,6,8,10,12,14,15,17,19,21,23,25,27,28 };
+
+static unsigned char pc2[48] = {
+	13, 16, 10, 23,  0,  4,  2, 27, 14,  5, 20,  9,
+	22, 18, 11,  3, 25,  7, 15,  6, 26, 19, 12,  1,
+	40, 51, 30, 36, 46, 54, 29, 39, 50, 44, 32, 47,
+	43, 48, 38, 55, 33, 52, 45, 41, 49, 35, 28, 31 };
+
+void deskey(key, edf)	/* Thanks to James Gillogly & Phil Karn! */
+unsigned char *key;
+int edf;
+{
+	register int i, j, l, m, n;
+	unsigned char pc1m[56], pcr[56];
+	unsigned long kn[32];
+
+	for ( j = 0; j < 56; j++ ) {
+		l = pc1[j];
+		m = l & 07;
+		pc1m[j] = (key[l >> 3] & bytebit[m]) ? 1 : 0;
+		}
+	for( i = 0; i < 16; i++ ) {
+		if( edf == DE1 ) m = (15 - i) << 1;
+		else m = i << 1;
+		n = m + 1;
+		kn[m] = kn[n] = 0L;
+		for( j = 0; j < 28; j++ ) {
+			l = j + totrot[i];
+			if( l < 28 ) pcr[j] = pc1m[l];
+			else pcr[j] = pc1m[l - 28];
+			}
+		for( j = 28; j < 56; j++ ) {
+		    l = j + totrot[i];
+		    if( l < 56 ) pcr[j] = pc1m[l];
+		    else pcr[j] = pc1m[l - 28];
+		    }
+		for( j = 0; j < 24; j++ ) {
+			if( pcr[pc2[j]] ) kn[m] |= bigbyte[j];
+			if( pcr[pc2[j+24]] ) kn[n] |= bigbyte[j];
+			}
+		}
+	cookey(kn);
+	return;
+	}
+
+static void cookey(raw1)
+register unsigned long *raw1;
+{
+	register unsigned long *cook, *raw0;
+	unsigned long dough[32];
+	register int i;
+
+	cook = dough;
+	for( i = 0; i < 16; i++, raw1++ ) {
+		raw0 = raw1++;
+		*cook	 = (*raw0 & 0x00fc0000L) << 6;
+		*cook	|= (*raw0 & 0x00000fc0L) << 10;
+		*cook	|= (*raw1 & 0x00fc0000L) >> 10;
+		*cook++ |= (*raw1 & 0x00000fc0L) >> 6;
+		*cook	 = (*raw0 & 0x0003f000L) << 12;
+		*cook	|= (*raw0 & 0x0000003fL) << 16;
+		*cook	|= (*raw1 & 0x0003f000L) >> 4;
+		*cook++ |= (*raw1 & 0x0000003fL);
+		}
+	usekey(dough);
+	return;
+	}
+
+void cpkey(into)
+register unsigned long *into;
+{
+	register unsigned long *from, *endp;
+
+	from = KnL, endp = &KnL[32];
+	while( from < endp ) *into++ = *from++;
+	return;
+	}
+
+void usekey(from)
+register unsigned long *from;
+{
+	register unsigned long *to, *endp;
+
+	to = KnL, endp = &KnL[32];
+	while( to < endp ) *to++ = *from++;
+	return;
+	}
+
+void des(inblock, outblock)
+unsigned char *inblock, *outblock;
+{
+	unsigned long work[2];
+
+	scrunch(inblock, work);
+	desfunc(work, KnL);
+	unscrun(work, outblock);
+	return;
+	}
+
+static void scrunch(outof, into)
+register unsigned char *outof;
+register unsigned long *into;
+{
+	*into	 = (*outof++ & 0xffL) << 24;
+	*into	|= (*outof++ & 0xffL) << 16;
+	*into	|= (*outof++ & 0xffL) << 8;
+	*into++ |= (*outof++ & 0xffL);
+	*into	 = (*outof++ & 0xffL) << 24;
+	*into	|= (*outof++ & 0xffL) << 16;
+	*into	|= (*outof++ & 0xffL) << 8;
+	*into	|= (*outof   & 0xffL);
+	return;
+	}
+
+static void unscrun(outof, into)
+register unsigned long *outof;
+register unsigned char *into;
+{
+	*into++ = (unsigned char)((*outof >> 24) & 0xffL);
+	*into++ = (unsigned char)((*outof >> 16) & 0xffL);
+	*into++ = (unsigned char)((*outof >>  8) & 0xffL);
+	*into++ = (unsigned char)(*outof++	 & 0xffL);
+	*into++ = (unsigned char)((*outof >> 24) & 0xffL);
+	*into++ = (unsigned char)((*outof >> 16) & 0xffL);
+	*into++ = (unsigned char)((*outof >>  8) & 0xffL);
+	*into	=  (unsigned char)(*outof	 & 0xffL);
+	return;
+	}
+
+static unsigned long SP1[64] = {
+	0x01010400L, 0x00000000L, 0x00010000L, 0x01010404L,
+	0x01010004L, 0x00010404L, 0x00000004L, 0x00010000L,
+	0x00000400L, 0x01010400L, 0x01010404L, 0x00000400L,
+	0x01000404L, 0x01010004L, 0x01000000L, 0x00000004L,
+	0x00000404L, 0x01000400L, 0x01000400L, 0x00010400L,
+	0x00010400L, 0x01010000L, 0x01010000L, 0x01000404L,
+	0x00010004L, 0x01000004L, 0x01000004L, 0x00010004L,
+	0x00000000L, 0x00000404L, 0x00010404L, 0x01000000L,
+	0x00010000L, 0x01010404L, 0x00000004L, 0x01010000L,
+	0x01010400L, 0x01000000L, 0x01000000L, 0x00000400L,
+	0x01010004L, 0x00010000L, 0x00010400L, 0x01000004L,
+	0x00000400L, 0x00000004L, 0x01000404L, 0x00010404L,
+	0x01010404L, 0x00010004L, 0x01010000L, 0x01000404L,
+	0x01000004L, 0x00000404L, 0x00010404L, 0x01010400L,
+	0x00000404L, 0x01000400L, 0x01000400L, 0x00000000L,
+	0x00010004L, 0x00010400L, 0x00000000L, 0x01010004L };
+
+static unsigned long SP2[64] = {
+	0x80108020L, 0x80008000L, 0x00008000L, 0x00108020L,
+	0x00100000L, 0x00000020L, 0x80100020L, 0x80008020L,
+	0x80000020L, 0x80108020L, 0x80108000L, 0x80000000L,
+	0x80008000L, 0x00100000L, 0x00000020L, 0x80100020L,
+	0x00108000L, 0x00100020L, 0x80008020L, 0x00000000L,
+	0x80000000L, 0x00008000L, 0x00108020L, 0x80100000L,
+	0x00100020L, 0x80000020L, 0x00000000L, 0x00108000L,
+	0x00008020L, 0x80108000L, 0x80100000L, 0x00008020L,
+	0x00000000L, 0x00108020L, 0x80100020L, 0x00100000L,
+	0x80008020L, 0x80100000L, 0x80108000L, 0x00008000L,
+	0x80100000L, 0x80008000L, 0x00000020L, 0x80108020L,
+	0x00108020L, 0x00000020L, 0x00008000L, 0x80000000L,
+	0x00008020L, 0x80108000L, 0x00100000L, 0x80000020L,
+	0x00100020L, 0x80008020L, 0x80000020L, 0x00100020L,
+	0x00108000L, 0x00000000L, 0x80008000L, 0x00008020L,
+	0x80000000L, 0x80100020L, 0x80108020L, 0x00108000L };
+
+static unsigned long SP3[64] = {
+	0x00000208L, 0x08020200L, 0x00000000L, 0x08020008L,
+	0x08000200L, 0x00000000L, 0x00020208L, 0x08000200L,
+	0x00020008L, 0x08000008L, 0x08000008L, 0x00020000L,
+	0x08020208L, 0x00020008L, 0x08020000L, 0x00000208L,
+	0x08000000L, 0x00000008L, 0x08020200L, 0x00000200L,
+	0x00020200L, 0x08020000L, 0x08020008L, 0x00020208L,
+	0x08000208L, 0x00020200L, 0x00020000L, 0x08000208L,
+	0x00000008L, 0x08020208L, 0x00000200L, 0x08000000L,
+	0x08020200L, 0x08000000L, 0x00020008L, 0x00000208L,
+	0x00020000L, 0x08020200L, 0x08000200L, 0x00000000L,
+	0x00000200L, 0x00020008L, 0x08020208L, 0x08000200L,
+	0x08000008L, 0x00000200L, 0x00000000L, 0x08020008L,
+	0x08000208L, 0x00020000L, 0x08000000L, 0x08020208L,
+	0x00000008L, 0x00020208L, 0x00020200L, 0x08000008L,
+	0x08020000L, 0x08000208L, 0x00000208L, 0x08020000L,
+	0x00020208L, 0x00000008L, 0x08020008L, 0x00020200L };
+
+static unsigned long SP4[64] = {
+	0x00802001L, 0x00002081L, 0x00002081L, 0x00000080L,
+	0x00802080L, 0x00800081L, 0x00800001L, 0x00002001L,
+	0x00000000L, 0x00802000L, 0x00802000L, 0x00802081L,
+	0x00000081L, 0x00000000L, 0x00800080L, 0x00800001L,
+	0x00000001L, 0x00002000L, 0x00800000L, 0x00802001L,
+	0x00000080L, 0x00800000L, 0x00002001L, 0x00002080L,
+	0x00800081L, 0x00000001L, 0x00002080L, 0x00800080L,
+	0x00002000L, 0x00802080L, 0x00802081L, 0x00000081L,
+	0x00800080L, 0x00800001L, 0x00802000L, 0x00802081L,
+	0x00000081L, 0x00000000L, 0x00000000L, 0x00802000L,
+	0x00002080L, 0x00800080L, 0x00800081L, 0x00000001L,
+	0x00802001L, 0x00002081L, 0x00002081L, 0x00000080L,
+	0x00802081L, 0x00000081L, 0x00000001L, 0x00002000L,
+	0x00800001L, 0x00002001L, 0x00802080L, 0x00800081L,
+	0x00002001L, 0x00002080L, 0x00800000L, 0x00802001L,
+	0x00000080L, 0x00800000L, 0x00002000L, 0x00802080L };
+
+static unsigned long SP5[64] = {
+	0x00000100L, 0x02080100L, 0x02080000L, 0x42000100L,
+	0x00080000L, 0x00000100L, 0x40000000L, 0x02080000L,
+	0x40080100L, 0x00080000L, 0x02000100L, 0x40080100L,
+	0x42000100L, 0x42080000L, 0x00080100L, 0x40000000L,
+	0x02000000L, 0x40080000L, 0x40080000L, 0x00000000L,
+	0x40000100L, 0x42080100L, 0x42080100L, 0x02000100L,
+	0x42080000L, 0x40000100L, 0x00000000L, 0x42000000L,
+	0x02080100L, 0x02000000L, 0x42000000L, 0x00080100L,
+	0x00080000L, 0x42000100L, 0x00000100L, 0x02000000L,
+	0x40000000L, 0x02080000L, 0x42000100L, 0x40080100L,
+	0x02000100L, 0x40000000L, 0x42080000L, 0x02080100L,
+	0x40080100L, 0x00000100L, 0x02000000L, 0x42080000L,
+	0x42080100L, 0x00080100L, 0x42000000L, 0x42080100L,
+	0x02080000L, 0x00000000L, 0x40080000L, 0x42000000L,
+	0x00080100L, 0x02000100L, 0x40000100L, 0x00080000L,
+	0x00000000L, 0x40080000L, 0x02080100L, 0x40000100L };
+
+static unsigned long SP6[64] = {
+	0x20000010L, 0x20400000L, 0x00004000L, 0x20404010L,
+	0x20400000L, 0x00000010L, 0x20404010L, 0x00400000L,
+	0x20004000L, 0x00404010L, 0x00400000L, 0x20000010L,
+	0x00400010L, 0x20004000L, 0x20000000L, 0x00004010L,
+	0x00000000L, 0x00400010L, 0x20004010L, 0x00004000L,
+	0x00404000L, 0x20004010L, 0x00000010L, 0x20400010L,
+	0x20400010L, 0x00000000L, 0x00404010L, 0x20404000L,
+	0x00004010L, 0x00404000L, 0x20404000L, 0x20000000L,
+	0x20004000L, 0x00000010L, 0x20400010L, 0x00404000L,
+	0x20404010L, 0x00400000L, 0x00004010L, 0x20000010L,
+	0x00400000L, 0x20004000L, 0x20000000L, 0x00004010L,
+	0x20000010L, 0x20404010L, 0x00404000L, 0x20400000L,
+	0x00404010L, 0x20404000L, 0x00000000L, 0x20400010L,
+	0x00000010L, 0x00004000L, 0x20400000L, 0x00404010L,
+	0x00004000L, 0x00400010L, 0x20004010L, 0x00000000L,
+	0x20404000L, 0x20000000L, 0x00400010L, 0x20004010L };
+
+static unsigned long SP7[64] = {
+	0x00200000L, 0x04200002L, 0x04000802L, 0x00000000L,
+	0x00000800L, 0x04000802L, 0x00200802L, 0x04200800L,
+	0x04200802L, 0x00200000L, 0x00000000L, 0x04000002L,
+	0x00000002L, 0x04000000L, 0x04200002L, 0x00000802L,
+	0x04000800L, 0x00200802L, 0x00200002L, 0x04000800L,
+	0x04000002L, 0x04200000L, 0x04200800L, 0x00200002L,
+	0x04200000L, 0x00000800L, 0x00000802L, 0x04200802L,
+	0x00200800L, 0x00000002L, 0x04000000L, 0x00200800L,
+	0x04000000L, 0x00200800L, 0x00200000L, 0x04000802L,
+	0x04000802L, 0x04200002L, 0x04200002L, 0x00000002L,
+	0x00200002L, 0x04000000L, 0x04000800L, 0x00200000L,
+	0x04200800L, 0x00000802L, 0x00200802L, 0x04200800L,
+	0x00000802L, 0x04000002L, 0x04200802L, 0x04200000L,
+	0x00200800L, 0x00000000L, 0x00000002L, 0x04200802L,
+	0x00000000L, 0x00200802L, 0x04200000L, 0x00000800L,
+	0x04000002L, 0x04000800L, 0x00000800L, 0x00200002L };
+
+static unsigned long SP8[64] = {
+	0x10001040L, 0x00001000L, 0x00040000L, 0x10041040L,
+	0x10000000L, 0x10001040L, 0x00000040L, 0x10000000L,
+	0x00040040L, 0x10040000L, 0x10041040L, 0x00041000L,
+	0x10041000L, 0x00041040L, 0x00001000L, 0x00000040L,
+	0x10040000L, 0x10000040L, 0x10001000L, 0x00001040L,
+	0x00041000L, 0x00040040L, 0x10040040L, 0x10041000L,
+	0x00001040L, 0x00000000L, 0x00000000L, 0x10040040L,
+	0x10000040L, 0x10001000L, 0x00041040L, 0x00040000L,
+	0x00041040L, 0x00040000L, 0x10041000L, 0x00001000L,
+	0x00000040L, 0x10040040L, 0x00001000L, 0x00041040L,
+	0x10001000L, 0x00000040L, 0x10000040L, 0x10040000L,
+	0x10040040L, 0x10000000L, 0x00040000L, 0x10001040L,
+	0x00000000L, 0x10041040L, 0x00040040L, 0x10000040L,
+	0x10040000L, 0x10001000L, 0x10001040L, 0x00000000L,
+	0x10041040L, 0x00041000L, 0x00041000L, 0x00001040L,
+	0x00001040L, 0x00040040L, 0x10000000L, 0x10041000L };
+
+static void desfunc(block, keys)
+register unsigned long *block, *keys;
+{
+	register unsigned long fval, work, right, leftt;
+	register int round;
+
+	leftt = block[0];
+	right = block[1];
+	work = ((leftt >> 4) ^ right) & 0x0f0f0f0fL;
+	right ^= work;
+	leftt ^= (work << 4);
+	work = ((leftt >> 16) ^ right) & 0x0000ffffL;
+	right ^= work;
+	leftt ^= (work << 16);
+	work = ((right >> 2) ^ leftt) & 0x33333333L;
+	leftt ^= work;
+	right ^= (work << 2);
+	work = ((right >> 8) ^ leftt) & 0x00ff00ffL;
+	leftt ^= work;
+	right ^= (work << 8);
+	right = ((right << 1) | ((right >> 31) & 1L)) & 0xffffffffL;
+	work = (leftt ^ right) & 0xaaaaaaaaL;
+	leftt ^= work;
+	right ^= work;
+	leftt = ((leftt << 1) | ((leftt >> 31) & 1L)) & 0xffffffffL;
+
+	for( round = 0; round < 8; round++ ) {
+		work  = (right << 28) | (right >> 4);
+		work ^= *keys++;
+		fval  = SP7[ work		 & 0x3fL];
+		fval |= SP5[(work >>  8) & 0x3fL];
+		fval |= SP3[(work >> 16) & 0x3fL];
+		fval |= SP1[(work >> 24) & 0x3fL];
+		work  = right ^ *keys++;
+		fval |= SP8[ work		 & 0x3fL];
+		fval |= SP6[(work >>  8) & 0x3fL];
+		fval |= SP4[(work >> 16) & 0x3fL];
+		fval |= SP2[(work >> 24) & 0x3fL];
+		leftt ^= fval;
+		work  = (leftt << 28) | (leftt >> 4);
+		work ^= *keys++;
+		fval  = SP7[ work		 & 0x3fL];
+		fval |= SP5[(work >>  8) & 0x3fL];
+		fval |= SP3[(work >> 16) & 0x3fL];
+		fval |= SP1[(work >> 24) & 0x3fL];
+		work  = leftt ^ *keys++;
+		fval |= SP8[ work		 & 0x3fL];
+		fval |= SP6[(work >>  8) & 0x3fL];
+		fval |= SP4[(work >> 16) & 0x3fL];
+		fval |= SP2[(work >> 24) & 0x3fL];
+		right ^= fval;
+		}
+
+	right = (right << 31) | (right >> 1);
+	work = (leftt ^ right) & 0xaaaaaaaaL;
+	leftt ^= work;
+	right ^= work;
+	leftt = (leftt << 31) | (leftt >> 1);
+	work = ((leftt >> 8) ^ right) & 0x00ff00ffL;
+	right ^= work;
+	leftt ^= (work << 8);
+	work = ((leftt >> 2) ^ right) & 0x33333333L;
+	right ^= work;
+	leftt ^= (work << 2);
+	work = ((right >> 16) ^ leftt) & 0x0000ffffL;
+	leftt ^= work;
+	right ^= (work << 16);
+	work = ((right >> 4) ^ leftt) & 0x0f0f0f0fL;
+	leftt ^= work;
+	right ^= (work << 4);
+	*block++ = right;
+	*block = leftt;
+	return;
+	}
+
+/* Validation sets:
+ *
+ * Single-length key, single-length plaintext -
+ * Key	  : 0123 4567 89ab cdef
+ * Plain  : 0123 4567 89ab cde7
+ * Cipher : c957 4425 6a5e d31d
+ *
+ * Double-length key, single-length plaintext -
+ * Key	  : 0123 4567 89ab cdef fedc ba98 7654 3210
+ * Plain  : 0123 4567 89ab cde7
+ * Cipher : 7f1d 0a77 826b 8aff
+ *
+ * Double-length key, double-length plaintext -
+ * Key	  : 0123 4567 89ab cdef fedc ba98 7654 3210
+ * Plain  : 0123 4567 89ab cdef 0123 4567 89ab cdff
+ * Cipher : 27a0 8440 406a df60 278f 47cf 42d6 15d7
+ *
+ * Triple-length key, single-length plaintext -
+ * Key	  : 0123 4567 89ab cdef fedc ba98 7654 3210 89ab cdef 0123 4567
+ * Plain  : 0123 4567 89ab cde7
+ * Cipher : de0b 7c06 ae5e 0ed5
+ *
+ * Triple-length key, double-length plaintext -
+ * Key	  : 0123 4567 89ab cdef fedc ba98 7654 3210 89ab cdef 0123 4567
+ * Plain  : 0123 4567 89ab cdef 0123 4567 89ab cdff
+ * Cipher : ad0d 1b30 ac17 cf07 0ed1 1c63 81e4 4de5
+ *
+ * d3des V5.0a rwo 9208.07 18:44 Graven Imagery
+ **********************************************************************/
diff -r 515d6e7ac66c tools/ioemu/d3des.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/ioemu/d3des.h	Thu Sep 21 14:19:04 2006 +0900
@@ -0,0 +1,51 @@
+/*
+ * This is D3DES (V5.09) by Richard Outerbridge with the double and
+ * triple-length support removed for use in VNC.
+ *
+ * These changes are:
+ *  Copyright (C) 1999 AT&T Laboratories Cambridge.  All Rights Reserved.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* d3des.h -
+ *
+ *	Headers and defines for d3des.c
+ *	Graven Imagery, 1992.
+ *
+ * Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge
+ *	(GEnie : OUTER; CIS : [71755,204])
+ */
+
+#define EN0	0	/* MODE == encrypt */
+#define DE1	1	/* MODE == decrypt */
+
+extern void deskey(unsigned char *, int);
+/*		      hexkey[8]     MODE
+ * Sets the internal key register according to the hexadecimal
+ * key contained in the 8 bytes of hexkey, according to the DES,
+ * for encryption or decryption according to MODE.
+ */
+
+extern void usekey(unsigned long *);
+/*		    cookedkey[32]
+ * Loads the internal key register with the data in cookedkey.
+ */
+
+extern void cpkey(unsigned long *);
+/*		   cookedkey[32]
+ * Copies the contents of the internal key register into the storage
+ * located at &cookedkey[0].
+ */
+
+extern void des(unsigned char *, unsigned char *);
+/*		    from[8]	      to[8]
+ * Encrypts/Decrypts (according to the key currently loaded in the
+ * internal key register) one block of eight bytes at address 'from'
+ * into the block at address 'to'.  They can be the same.
+ */
+
+/* d3des.h V5.09 rwo 9208.04 15:06 Graven Imagery
+ ********************************************************************/

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

RE: Individual passwords for guest VNC servers ?

[Ian Pratt]

>   - A password has to be encoded in base64 format.  For example, you
can
>     obtain one by executing the next command.
>         # cat ~/.vnc/passwd | uuencode -m passwd | head -2 | tail -1

Nice work.

Didn't someone suggest that there was some better tool than uunecode for
getting the password printable? One that was in the 'base' of most
distros? (which I don't think uuencode is)

It would be nice if we had a script that invoked the 'vncpasswd' and the
above encoding to print the string to cut and paste.

Thanks,
Ian

 
> Configuration examples:
>   - No password authentication for all VNC consoles.
>         --- xend-config.sxp ---
>         (vncpasswd  '')
>         -----------------------
> 
>   - Single common password for all VNC consoles.
>         --- xend-config.sxp ---
>         (vncpasswd 'PASSWORD')
>         -----------------------
> 
>   - VM-specific password for vm1.
>         --- vm1 config --------
>         vncpasswd = "PASSWORD for vm1"
>         -----------------------
> 
> Notes and request:
>  - On log file permissions.
>    Please mind logfile permissons since password are recorded in
>    xend and qemu-dm logfiles, though they are not decoded.
>  - On DES (Data Encryption Standard).
>    Please check the copyright notes in d3des.h and d3des.c and the
>    description that says "a portable, public domain, version of the
Data
>    Encryption Standard."
>    I needed the DES module in standard VNC.  So I included these files
>    without modification from VNC 4.1.1 source distribution for Unix
>    platforms.
> 
> Other notes:
>  - I tested that the following VNC clients successfully negotiated to
>    the VNC console.
>         VNC Viewer Free Edition 4.1.1 for X
>         VNC Free Edition for Windows Version 4.1.2
>         UltraVNC Win32 Viewer 1.0.2
> 
> 
> Signed-off-by: Masami Watanabe <masami.watanabe@jp.fujitsu.com>
> 
> Best regards,
> Watanabe
> 
> 
> 
> On Thu, 31 Aug 2006 11:45:37 +0100, Ian Pratt wrote:
> > > I take your point about security, I'll do as follows.
> > > - vnc_passwd is not omissible.
> > > - The domain cannot be created if there is no vnc_passwd.
> >
> > It would also be good to be able to specify a system-wide vnc
password
> > in the xend-config.sxp that is overridden by individual guest
configs.
> >
> > Thanks,
> > Ian
> >
> > > > On Thu, Aug 31, 2006 at 10:23:56AM +0900, Masami Watanabe wrote:
> > > > > I'm thinking of adding the following protection to VNC
console.
> > > > > I know it's not perfect, nonetheless, it's far better than the
> > current
> > > > > no protection situation. Please comment.
> > > > >
> > > > > Specification:
> > > > > - The same challenge-response auth scheme as standard VNC to
be
> > > available
> > > > >   from VNC viewer (like RealVNC).
> > > >
> > > > Yeah, looking at the various clients, challenge-response is the
only
> > one
> > > > we can really rely on being present - in fact its the only one
> > supported
> > > > by Fedora VNC client (RealVNC IIRC?) at all.
> > > >
> > > > > - The vnc password of each VM is described in the VM
configuration
> > > file.
> > > > >   When omit the password, do not use authentification.
> > > > >     ex) vnc_passwd = xxxxx
> > > >
> > > > I think we should be secure by default - if they omit the
password
> > then
> > > > we should either generate one - and store it in xenstore, or
refuse
> > to
> > > > activate VNC server. If we really really want to allow no
passwords,
> > then
> > > > admin could have to explicitly request it with vnc_no_password=1
> > > > in the config file - but my prefernce is still that we should
flat
> > out
> > > > refuse to allow an empty password - in this day & day its just
plain
> > > wrong.
> > > > RealVNC server for example, refuses to allow empty password.
> > > >
> > > > > - Where "xxxxx" is an uuencoded encrypted password, that is,
> > > > >   you can get this value by
> > > > >   # cat ~/.vnc/passwd | uuencode -m passwd
> > > > >     (needs uuencode command: sharutils package)
> > > >
> > > > Perhaps base64 would be preferable - that's a standard part of
Linux
> > > > coreutils toolset, rather than an addon like uuencode is.
> > > >
> > > > 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

Re: Individual passwords for guest VNC servers ?

[Daniel P. Berrange]

On Fri, Sep 22, 2006 at 09:04:38PM +0900, Masami Watanabe wrote:
> Specification:
>   - This is only for HVM domain.

No problem, looks easily adaptable for the paravirt FB code when that is
finally ready for merge.

>   - xend-config.sxp (for system-wide) and VM configuration files (for
>     VM-specific) can have a VNC password description.
>   - A HVM domain bringing up VNC console needs at least one password
>     description ether in xend-config.sxp or its VM configuration file.
>   - A VM-specific password takes effect if both system-wide and
>     VM-specific passwords exist.
>   - Password descriptions look like the following.  An empty string for
>     vncpassword means no authentication.
>         VM configuration file:  vncpasswd = 'string'
>         xend-config.sxp      : (vncpasswd   'string')
>   - A password has to be encoded in base64 format.  For example, you can
>     obtain one by executing the next command.
>         # cat ~/.vnc/passwd | uuencode -m passwd | head -2 | tail -1
> 
> Configuration examples:
>   - No password authentication for all VNC consoles.
>         --- xend-config.sxp ---
>         (vncpasswd  '')
>         -----------------------
> 
>   - Single common password for all VNC consoles.
>         --- xend-config.sxp ---
>         (vncpasswd 'PASSWORD')
>         -----------------------
> 
>   - VM-specific password for vm1.
>         --- vm1 config --------
>         vncpasswd = "PASSWORD for vm1"
>         -----------------------
> 
> Notes and request:
>  - On log file permissions.
>    Please mind logfile permissons since password are recorded in
>    xend and qemu-dm logfiles, though they are not decoded.

It seems the password is also trivially viewable by running 

 ps -axuwwf | grep qemu-dm

Sure its obfuscated, but that's easily reversable to get the actual
password.

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'

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.


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  -=| 

RE: Individual passwords for guest VNC servers ?

[Ian Pratt]

> 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

Re: Individual passwords for guest VNC servers ?

[Anthony Liguori]

Ian Pratt wrote:
>> Passing around passwords either on the command line, or environment is
>>     

VNC password is very easy to support.  The only problem is storing the 
password (as everyone seems to understand).  One thing I want to point 
out though is that the VNC password is almost plain-text equiv at this 
point.

There are some more interesting things that can be done to secure VNC 
(like tunnel it through ssh).  It would be nice to consider automating 
this sort of thing if we're going to try and attempt to implement 
security features.

Regards,

Anthony Liguori

Re: Individual passwords for guest VNC servers ?

[Daniel P. Berrange]

On Fri, Sep 22, 2006 at 02:54:24PM +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 long as XenD makes sure its DB is not world readable, this sounds
reasonable.

> > 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.

Yeah, that's probably best solution particularly since qemu-dm is
already reading/writing to the xenstore it should be little work
to also fetch the password from there.


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  -=| 

RE: Individual passwords for guest VNC servers ?

[Masami Watanabe]

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

Re: Individual passwords for guest VNC servers ?

[Anthony Liguori]

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
>>     
>
>   

RE: Individual passwords for guest VNC servers ?

[Ian Pratt]

 
> 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?

The xend life cycle management patches were posted by Alistair a couple
of months back. They'll go in early in the 3.0.4 cycle.

>   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.

In the mean time, I'd just out them in the domain config file and change
the default permissions and ownership.

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

It can be passed transiently (i.e. it gets deleted from the store by
qemu-dm)
You need to be root to run xenstore-ls so I'm comfortable with this.

Ian

RE: Individual passwords for guest VNC servers ?

[Masami Watanabe]

> In the mean time, I'd just out them in the domain config file and change
> the default permissions and ownership.


Yes, I'll do as follows. 

I challenge the correction that uses xenstore. 
When the password is received, qemu-dm deletes it. 

Masami Watanabe


On Tue, 26 Sep 2006 19:23:47 +0100, Ian Pratt wrote:
>  
> > 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?
> 
> The xend life cycle management patches were posted by Alistair a couple
> of months back. They'll go in early in the 3.0.4 cycle.
> 
> >   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.
> 
> In the mean time, I'd just out them in the domain config file and change
> the default permissions and ownership.
> 
> > 2. Method of Xen VNC Server receiving stored password
> >   By way of xenstore. However, it is necessary to consider 
> > xenstore-ls.
> 
> It can be passed transiently (i.e. it gets deleted from the store by
> qemu-dm)
> You need to be root to run xenstore-ls so I'm comfortable with this.
> 
> Ian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Individual passwords for guest VNC servers ?

[Masami Watanabe]

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