First off, thanks to you and Martin on providing the condensed
security howto. I had been digging it up from older VNC lists when
you sent it. I knew options were available but was just not sure on
the correct syntax for passing them. I am now getting the right
prompts for username and password but it fails everytime when the
correct one is entered. I created the /etc/pam.d/vnc file. Are
there any other steps to this or maybe some permissions issues to
deal with? I am doing this on Debian Lenny 64 with a SVN compiled
TigerVNC server with TLS enabled. I am really looking forward to
testing the 1.1 release. Would love to do away with the VncAuth
portion while I am at it...
Robert
On 02/10/2011 05:11 PM, DRC wrote:
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
--
Robert Goley
FOSS
Implementation Specialist
Toll Free: (800) 338-4984
Local: (770) 479-7933
Fax: (770) 479-4076
www.openrda.com
America's only Free & Open Source
fund accounting software company.
|
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
