On 7/22/10 12:27 AM, Martin Koegler wrote:
>> -- A set of "allowed" security types can be configured for the VNC
>> server. It should be possible for a SysAdmin to specify this in a
>> central config file, which will take precedence over command line
>> options or per-user config files (thus, if a SysAdmin decides, for
>> instance, to disable the use of VncAuth, the user can't override this
>> decision.)
>
> If the user has shell access and the vnc server is started using the
> uid of the user by the user (eg. not by inetd), a user can bypass the
> sysadmin setting (eg. by starting a modified version from $HOME).
>
> As Xvnc can run as any user, I would like to stick to the normal user
> unix default for such unprivileged programs: parameters take precedence
> over config file.
This makes the use of extended authentication types somewhat useless
from the point of view of a SysAdmin, though. If there is not a way for
them to enforce, or at least strongly encourage, the use of secure
authentication on a system-wide level, then any user can choose to use
VncAuth or VncNone.
The way we do things in TurboVNC is to have a separate config file,
/etc/turbovncserver-auth.conf, which is hard-coded into the Xvnc
executable. Thus, the user has no ability to override this without
re-compiling Xvnc (which, trust me, isn't something that a user is going
to do with TigerVNC. It's hard enough for us to compile it!)
>> -- The default set of allowed security types for the server is the set
>> of all security types that TigerVNC supports, with VncAuth being the
>> first entry and VncNone being the last. Thus, any viewers that do not
>> override the default will revert to using the legacy VNC password
>> authentication. However, the SysAdmin can change the set of allowed
>> security types on the server side to force all viewers to use something
>> more secure than VncAuth.
>
> I would not enable the *None by default in the server, as anybody can
> connect to it. Its easy to start Xvnc and forgetting to set
> SecurityTypes.
Sorry, I was thinking in TurboVNC terms. The way our auth extensions
work is that there are "allowed" and "enabled" authentication types. An
authentication type is "allowed" if the SysAdmin has listed it in the
authentication configuration file, or, if that file doesn't exist or the
relevant entry is unspecified, then the default set of allowed types is
{VNC password, one-time password, PAM, None}. However, each of these
auth types must be enabled by passing a command line argument to Xvnc,
and None is only enabled if no command line arguments are passed to
Xvnc. The -rfbauth argument changes meaning such that it not only
specifies the VNC password file but enables VNC password auth as well,
and there are additional arguments to enable OTP and PAM.
I like this system, because it allows the user to enable specific auth
types on a session-by-session basis, but it allows the SysAdmin to
constrict that set.
The -securityTypes argument is a cleaner way to do this. I'm just
proposing that there be a way for SysAdmins to restrict the set of
security types that a user can specify in their Xvnc session.
>> If I understand correctly, then using the -securityTypes argument to
>> vncserver and vncviewer addresses most of this, but correct me if I'm wrong.
>
> There is no config file support in Xvnc and vncviewer.
I will need to implement an auth config file of some sort if I ever
deign to port the PAM authentication support over to TigerVNC, so that
would be the appropriate time to revisit having some sort of mechanism
for the SysAdmin to specify the security types globally.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
