Bug#299007: base-files: Insecure PATH
On Tue, Mar 22, 2005 at 09:20:41PM +1100, psz@maths.usyd.edu.au wrote:
> 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?
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.
Reply to: