On Tue, Mar 22, 2005 at 09:20:41PM +1100, wrote: > Manoj Srivastava wrote: > > >> The fact, though, is that this is a privilege escalation from the > >> (documented, but essentially unused) 'staff' group to root. > > ... > > ... you can use [group staff] to allow people who already have the > > root password to perform some tasks while they are not root. > > Is this feature seldom used, so we do not care much about it; or is it > often used, and so possibly worth retaining? Well, I certainly use it. I also create multiple non-root accounts for people trusted to do 'root' things: A 'mortal' account for reading mail and other normal work and one or more 'almost root' accounts for doing things like manipulating /usr/local, installing software etc. Such an 'almost root' account may or may not be a member of group 'staff' (some are, some are not, depending on needs). > > In the default, unused state, it may be somewhat safe: it is not safe if > you use NFS (in some common configurations). In the used state it is > less safe: with or without NFS it may be possible to trojan the non-root > staff user. Either way, the feature decreases security; this risk is not > documented. I assert that in some common configurations the exposure is > unacceptably high. > All secure operating systems that I work with include various groups or similar that are subsets of root privileges with an acknowledged potential of abusive escalation to full root. Some go all the way and eliminate direct access to the root account entirely, for instance 'adduser' on such systems might by rwsr-x--- root admins or similar mechanisms. It is thus fundamental to the security of any modern system that the core OS infrastructure prevents 'become-trusted-group-bugs' as strongly as they prevent 'become root directly' as these are equivalent in the face of a competent, malicious attacker. For instance most Unix/POSIX filesystems prevent creation of sgid binaries (one of the example attack vectors mentioned) to people already in that group. All but the most lousy security systems prevent manipulation of other users files (another example attack vector) by anyone not authenticated to do so. The real, fundamental, security issue is that most implementations of the NFS protocol blindly assume that none of the client machines have had their local authentication systems compromised in any way. These broken-by-design NFS implementations are completely open to full attacks against any accounts or groups allowed access from the network. If just one machine on the network (with a trusted or spoofed IP address) makes it possible to send incorrect uids or gids to the NFS server, then that machine can be used to trojanize any and all user writable files, for any user. If home directories are NFS mounted by *other* machines, all users of those accounts can then be trojanized by changing the personal login scripts on the NFS server. Thus once any such exploit occurs on an NFS system, the individual group staff/bin/disk/admin/whatever memberships or permissions are the least of your worries: The network has become completely taken over and all systems should be given the 'root compromise' cleanup. > Should you wish to retain the feature, you must document the risk > associated with it. > > Is it documented anywhere that you should only give group staff > privileges to those that also have the root password? > I think it is probably documented somewhere (and certainly basic os-independent sysadmin knowledge) that most systems include such groups and that any predefined group with either no members or only special accounts as members should be assumed to have this property, unless documented not to. > > > ... forcing the admin to run as root all the > > time reduces, rather than enhances, system security. > > Accepting that statement, is not "forcing" your admin to run as group > staff all the time, also bad? Good admins do most things as their mortal > selves, and only do the "rootly" things as root: su or login when really > needed. Then at least they get a distinction between their powerless > and powerful states; being in group staff you have the power all the > time, and cannot give it up. See my example above (creating multiple accounts for admin people, so they can get/drop staff membership with su-to-non-root or multiple login screens (Linux VTs come in very handy here)). Another option, found only on Unix/Linux systems is to assign a password to group staff in /etc/gshadow and then use newgrp(1) or sg(1) commands to get and give up group staff membership as needed. > > Security is mostly about protecting from malice, not about protecting > from shoot-yourself-in-the-foot mistakes. (You cannot make things > foolproof, because fools are quite inventive.) > Agreed on the purpose of security, but not on not *also* using it to foolproof things or make attacks more difficult. Practical fool-proofing is about reducing accident probabilities not making things impossible. This is why most actual firearms have a safety catch: It prevents people from literally shooting themselves in the foot when they are simply trying to move their firearm in and out of its holster. Actual press reports on the opposite happening when our local police was issued new guns without any safety catch and the 'They are just incompetent in handling the weapon, throw them out of the force' official responses come to mind. > > ... sudo and super can be set up to allow trivial privilege > > escalations ... all kinds of tools and mechanisms that can be set up > > badly; but that does not mean that we should ban them out of hand. > > Should make a distinction between what *can* be set up badly, and what > *is by default* bad. We ban bad-by-default things; we warn against > common or easy-to-make-a-mistake misconfigurations. > Agreed again. > At no time was I arguing for banning whatever ownership of /usr/local by > policy; I only wanted to also allow it being owned by root. I understand > that you may wish to retain your group staff feature and privileges: > your machine, your right to run it any way you like; its (in)security is > your responsibility alone. However, you must also grant me the right to > run my machine securely, and should not try to prevent me from doing so > by policy. > NOT agreed. Granting group staff root-escalatable privileges in usr/local or elsewhere is not the problem. Having any deliberately root-escalatable groups is not the problem. Having any non-root users trusted to become root without a second password entry (like what sudo provides) is not the problem. The problem is that most NFS-servers and most versions of the NFS protocol do not perform sufficient validation that users have been authenticated to be whom they claim to be. Blocking access with selected highly accounts such as root or sometrustedperson or group staff/bin/whatever is only a partial, stop-gap measure. The proper solution is for the NFS-server to validate (directly or via another trusted server) that requests to access exports as user X come from a machine where user X is actually authenticated. I believe that such facilities do exist in many modern NFS servers and clients, but have not checked it further as I avoid NFS altogether in favor of better designed protocols. Kerberos-authenticated NFS is one such possibility, but not necessarily the only or best one. Side note: As a security specialist I am increasingly annoyed by this kind of loud shouting about security pseudo-bugs drowning out real security discussions and frequently forcing vendors to make extremely ill-advised system changes that actually harm security or users or both. Removing group staff access to /usr/local would be such an ill-advised change. Cheers Jakob Bohm, M.Sc.Eng. -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.