Bug#299007: base-files: Insecure PATH
Manoj Srivastava <srivasta@debian.org> 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 psz@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
Reply to: