On 2/18/11 2:18 AM, Martin Koegler wrote: > The traditional unix way of steering the user behaviour is the > following settings preference: > 1) Parameter specified on the command line > 2) Parameter in the config file in $HOME > 3) Parameter in the config file in /etc > 4) Last fallback: compiled in defaults > > This way, the admin can set sytem defaults. He is still aware, that > the users can override it and can take counter measures on a level, he > has full control of [eg. firewall]. > > Your approach gives a false sense of security to clueless admins: They > think, that they can control the behaviour and therefore avoid other > security measures.
So you think that just because a SysAdmin prefers both belt and suspenders to just a belt, that makes them clueless? Speaking as a former SysAdmin, I can tell you that it's not either/or-- it's both. Your argument basically boils down to, "we shouldn't give the SysAdmin the ability to take any security measures that aren't bulletproof, because it gives them a false sense of security." Well, by that logic, I shouldn't wear a seatbelt when I drive, because it will give me a false sense of security, and it probably won't save my life if I accidentally drive off a cliff. There are reasons other than security to implement this change. Providing a uniform system environment is arguably an even stronger reason. If you're having to support thousands of users, you want to present them with an interface that makes intuitive sense to them, because that way they will be less likely to call you at 11 PM at night wanting tech. support. A typical deployment for the TurboVNC auth extensions might be: (1) The server authentication configuration file specifies that only user/password and one-time password auth are allowed, in that order. (2) The same file specifies that only local connections are allowed (forcing people to use SSH tunneling.) (3) The same file specifies that reverse connections are not allowed. The machine is behind a corporate firewall, but it typically has a software firewall as well. Belt and suspenders. Now, when someone connects using a VNC viewer that supports the Tight Security Extension, it will present them with the user/password dialog that they're used to. Once in the TurboVNC session, they can generate a one-time password to allow other users to collaborate with them. Since the OTP system uses regular VNC authentication, it is necessary for the server security types order to be honored for the above scenario to work right. The main reason for this, again, is usability, not security. The SysAdmin wants the clients to always be presented with a user/password login dialog unless they are specifically logging in to collaborate with another user. VncAuth has to be left enabled, because you may have collaborators who have a less capable VNC client. However, you don't want it to be preferred, because it is being used with a one-time password system, not the regular VNC auth. system. At any rate, this discussion is getting quite pointless. I've given more than adequate justification as to why I need this, both on security grounds as well as usability grounds. Unless there are concrete, not philosophical, objections, I don't see any reason not to proceed. ------------------------------------------------------------------------------ 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
