VNC development plan - discuss

[Daniel P. Berrange]

On Tue, Mar 06, 2007 at 08:46:24PM +0000, Mike Cohler wrote:
> Adam Tkac <atkac <at> redhat.com> writes:
> 
> > features than actual "real desktop" servers. So two programs could be 
> > removed and one added => cost of maintaining and bugfixing could be 
> > lower. In next stage we could discuss about standardized RFB protocol 
> > library which could be used by all vnc servers in distro. In the end we 
> > could have one rfb library which will be used by all servers (and 
> > viewers), one real server, one virtual server and X module. What do you 
> > think about this idea?

Since we're on the subject of VNC servers, its a good time to bring up the
question of virtualization. With Xen in the mix there are actually 2 further
VNC server implementations in Fedora...

   - Xen para-virtualized guest console server
   - QEMU / KVM / Xen fully-virtualized guest console server

The former is currently based on libvncserver which turned out to be an 
really bad mistake. The code is horribly complicated / obtuse and has 
completely unsafe use of pthreads synchronization primitives. The QEMU VNC
server is a from sratch impl of the RFB protocol which is directly part of
the QEMU codebase.  It is my intention that the current Xen paravirt VNC
server will be re-written to use more-or-less the same code as the current
QEMU impl, which will bring it down from ~20,000 lines of C, to ~2,000.
Now this isn't directly relevant, since the code isn't really suitable for
turning into a standalone VNC server. I just wanted to point out that 
you should be wary of picking libvncserver as the basis of a shared RFB
impl in its current form, since the codebase isn't all that nice to work 
with.

The whole discussion of merging VNC servers though misses out the most 
critical shortcoming in VNC - it has a non-existant security model. All
traffic is clear-text on the wire, and the authentication is trivially
brute-forced. Tunnelling it over SSH is really just a band-aid, because
even with it restricted to listen on 127.0.0.1 any local user can still
trivially compromise any other user's session

For the virtualization arena, tunnelling over SSH is out of the quesiton
because integrity of the host system is too important. You don't want to
have to give out login accounts to the host just so that a user can access
the guest virtual console. So for Xen / QEMU I am currently working on 
implementing native SSL support in their respective VNC server impls, based
on the protocol defined by VeNCrypt. I expect this work to arrive some
time in the Fedora 8 dev cycle, which is when we hope to have full-remote 
management capabilities for Xen / QEMU / KVM. 

The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that
supports encryption aside from SSH tunnelling - not a huge problem since 
virt-manager has an embedded GTK VNC widget which can do the job, but it
would be nice to have a standalone viewer for virtual machine consoles.

So if we're thinking of long term Fedora VNC development plans, we should 
make sure encryption / authentication is on the list for both client & 
server.

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