VNC development plan - discuss

[Adam Tkac]

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