On 2/10/11 3:39 PM, Robert Goley wrote:
> What are the SecurityType options that must be passed to enable it?
> This would be useful in benchmarking differences between TLS and non TLS
> connections...
On the server:
-SecurityTypes=VeNCrypt,Plain -PlainUsers={comma-separated list of
allowed users}
You also have to create a new PAM service called "vnc". I did this by
copying /etc/pam.d/passwd to /etc/pam.d/vnc, but different systems do
this differently. Some systems may use a pam.conf file, in which case
you'd copy the [passwd] stanza to a new stanza called [vnc].
on the viewer:
-SecurityTypes=VeNCrypt,Plain
(also controllable through the GUI.)
One of the things I want to port over from TurboVNC is the per-session
access control list. With that system, if user/password auth is
enabled, then the creator of the Xvnc session is automatically granted
access using that auth method. Then, he/she can use a special option to
vncpasswd to grant additional user names either view-only or full
control access (and subsequently revoke same) while the session is running.
Another security extension we have is a centralized config file that
allows the SysAdmin to globally disable reverse connections and to
globally require that TurboVNC connections be made only to/from
localhost (to force SSh tunneling to be used, which is a good idea in
conjunction with the plain text user/password method.) It's not 100%
hackproof, but in a reasonably "locked down" enterprise environment, it
seems to work well enough. Users would basically have to build their
own custom version of TurboVNC to circumvent it, and what's the impetus
for doing so? If they want to compromise their own password, they could
just post it up on the bulletin board down the hall and save themselves
the trouble.
I'm OK with requiring VeNCrypt for the time being to get the
user/password functionality, but in the long term, it may be necessary
to re-implement a method of doing this that doesn't require VeNCrypt.
This is mainly because VeNCrypt is so difficult to work with on Windows
(more on that in a subsequent e-mail.)
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
