This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Masami Watanabe <masami.watanabe@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Individual passwords for guest VNC servers ?
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Thu, 31 Aug 2006 02:38:40 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 30 Aug 2006 18:39:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <JC2006083110235610.59547031@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060816181153.GC25831@xxxxxxxxxx> <20060825004436.GL809@xxxxxxxxxx> <JC2006083110235610.59547031@xxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
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.

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