Xen devel - Aug 2006 - Individual passwords for guest VNC servers ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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