Manoj Srivastava <[EMAIL PROTECTED]> 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? 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. 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? > While in a role as group staff, some of the consequences of > actions taken in error ... You need to train admins to be careful. You should train them to use "rm -i" e.g. via aliases. With power comes responsibility. How is it acceptable to not be protected against "rm -rf /home/userdir"? (Is rm the only dangerous command?) > ... 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. 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.) > ... 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. 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. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
