On 7/23/10 3:40 AM, Martin Koegler wrote: > On Thu, Jul 22, 2010 at 04:02:52PM -0500, DRC wrote: >> 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. > > A SysAdmin can't prevent a user from doing this. For normal (shell) user > processes, he can only suggest defaults. > > If a sysadmin wants to control VNC use, has to: > * Install a firewall on the server preventing inbound connection > * Start vnc on some ports under a system user (eg. via inetd) > > Even in that case, the user can still start his own Xvnc server, but > he needs to tunnel remote access.
You're missing my point. What I'm trying to do is implement a mechanism whereby the SysAdmin can set global defaults for all TigerVNC server sessions on the system. Yes, there are always ways to hack around this, but the idea is to make it difficult enough to hack around that most users won't bother. If a SysAdmin prefers that the insecure security types, such as VncAuth, not be exposed by default, then they should be able to at least make it difficult for a user to use those types. You are coming at this from the point of view of a developer. Most users do not know how to, nor do they have the time to, set up their own version of Xvnc and run it from their home directory. >> 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!) > > If the defaults are sensible, the user will not override them. If the > user is annoyed by the sysadmin setting, he will search for alternatives. > > The user is not required to recompile it himself. User are likely to > start exchanging modifed, precompiled version. > > If TurboVNC has not taken extra precautions, a 1-2 lines shell script > should be sufficient to prevent it from using the sysadmin defaults. Care to provide specifics? I do not see how someone could enable a security type that the SysAdmin has disabled in the auth. config file unless they either compile their own Xvnc or use a binary editor to modify the embedded path of the authentication configuration file. In either case, the user will know very clearly that they are doing something that the SysAdmin does not intend them to do. There is no such thing as 100% security, but that doesn't mean that improved security isn't worth pursuing. Corporate users do not have time to mess with recompiling or trading their own custom versions of Xvnc, and if they did, a stern warning from the CIO would likely curb the behavior. >> 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. > > PAM support would not fit in a normal config file. It requires a file > /etc/pam.d/<service-name> specifying the list of pam modules. > > The Plain security needs only needs another option specifing, that it > should use a pam based password validator and maybe allows to override > the service-name passed to PAM. I don't follow what you're saying. Yes, a file has to be created under pam.d. Furthermore, the SysAdmin has to specify the name of this file in the auth. config file so that Xvnc knows what PAM service name to use. That is not something that should be left for the user to decide-- most users wouldn't even know what to specify. Again, what I'm going for is not a hack-proof version of Xvnc. What I'm going for is a way for SysAdmins to specify security defaults and make it difficult for users to override these. TurboVNC's authentication extensions were designed by people who are successfully using them in a large-scale academic environment. ------------------------------------------------------------------------------ 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
