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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
