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