[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: VNC development plan - discuss



Daniel P. Berrange napsal(a):
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.

Don't tell me about xen's virtual console. I have dreams about nasty mouse tracking (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221360) every night. If you're going to do major changes on vnc bits in xen, I'm ready to help you with this development. If you're really looking for good RFB Protocol implementation I think that RealVNC's implementation is best (stable, robust, c++ implementation for server and viewer side). Recently I've created package named vnc-libs (in rawhide) which contains this implementation. You could write me mail if this solution sounds good for you ;)

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.

You're right. Current VNC security model was good in 80s but nowadays is complete unusable. I want make vnc secure but protocol is protocol... (http://www.realvnc.com/docs/rfbproto.pdf). We can't make RedHat's vnc which will have perfect security policies but which is incompatible with other vnc implementations. Btw VeNCrypt looks fine. I could do investigations what could be ported to our vnc to improve security.

Regards,
Dan.

Regards, Adam


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]