Wow, our company does the same thing, and we discover the VNC is not very
efficient with multiple connections, so for that propose we wrote VNCProxy.
The proxy connects to the VNC server with a single connection and tunnel the
data stream to its clients. I guess that we can make the source code for it
available soon.
P.S. just thought of it, you can imp the security layer on the proxy it
doesn't have to be on the VNC Server.
Cheers,
Shay
-----Original Message-----
From: William Yang [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 19, 2001 11:39 PM
To: [EMAIL PROTECTED]
Subject: VNC security (uhm... maybe a feature request)?
Hello.
I'm a network and security analyst for the OSC (Ohio Supercomputer
Center) in Columbus, Ohio, USA. First off, let me say that I and my
organization generally has been very impressed with the functionality
of VNC. We've been using VNC to share a desktop in seminars -- a
"master" who demonstrates something, and some number of slaves who are
simply spectators, viewing what's going on. We've used this in the
past for multi-location conferences, to permit people all over the
world to view our desktop as we give multicast audio/video
presentations across the Internet. See www.accessgrid.org for more
information on our approach.
Unfortunately, VNC does not really support any kind of (enforced)
seperation of these two kinds of users. The underlying issue, from a
security standpoint, is that VNC doesn't differentiate between
authentication and authorization: if you authenticate at all, you're
authorized (as far as VNC is concerned) to do whatever you want on the
server. From a security standpoint, it'd be useful to see
segmentation between the "view" mode and the "modify" mode (where your
input is actually processed by the server).
To faciliate "online seminars" it'd be useful to post a VNC password
and port at a host on, say, a web page. Unfortunately, once you've
got that password, you're able to run whatever you want on the server,
so a vandal could claim to be a "master" during the seminar and
disrupt the sessions, or could come in just before or just after the
seminar and run arbitrary code, disrupting the security of the host
and the network we operate.
To resolve this problem, it would be helpful if there could be some
way to specify a different "view-only" password that would be
different from a "full control" password. Then, master sessions could
run over an SSH tunnel and protect the password of anyone who's
capable of changing the running session in any way, and all viewers
could run without SSH for better performance and without a threat to
the security of the host and network the VNC server is on.
I've only passingly scanned the protocol: it's not clear to me that
the protocol itself supports this kind of functional seperation.
Might it be possible to see this seperation as an extension in future
versions of VNC, should I be working on patches, or is it going to be
more advantageous to build chroot'd and highly restrictive X
environments for the server?
Thanks in advance,
-Bill
--
William Yang
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
