Re: Got root?

[Andres Salomon <dilinger@mp3revolution.net>]

On Tue, May 01, 2001 at 11:25:49AM +0100, Tim Haynes wrote:
> 
> Andres Salomon <dilinger@mp3revolution.net> writes:
> 
> > Perhaps I'm misunderstanding your proposition, but how is this different
> > than, say, having inetd listen on ports below 1024, and then
> > forking/changing to a different user once a connection is made to the
> > port?
> 
> The current method you describe was vulnerable to bugs concerning setuid(),
> as per the 2.2.15->16 bug found by sendmail - having come from root and
> called stuid() to become someone else, it was still possible to return to
> being root, at which point you have a root daemon running on a port: Bad.

Good point, but from what I understand of this bug (disclaimer: I haven't
looked into it that much), it was a mixture of dropping privs in setuid()
and capabilities.  What's to stop something similar from popping up in
code dealing w/ capabilities alone?  The fact that a process was coming
from root was only a small part of the equation, if I understand correctly.

> 
> If you do it via capabilities in the first place, you never need to have
> *been* root in order to bind to the low port.

OTOH, by originating from root, you're assured of proper privledges.  If
you can obtain root (either w/ a valid login, a setuid bit, controlling
the execution of another process.. whatever), the system assumes
you have the authority to open ports below 1024, and potentially use
them to trick other hosts (why bother with man-in-the-middle attacks when
you can simply be the man-at-the-other-end?).  If the proposal did something
that limited a uid 0 process' ability to; for example, restricting it to
_only_ listen on a port; I would be fine w/ that.  However, this proposal
heightens privledges from a normal user (executing a "special" binary) to
one w/ more power.  Kernel and security bugs (as well as admin/distribution
default foolishness) aside, this means that:

a) If I happen to be a random user on the system, I can start up a daemon
that the admin has stopped for whatever reason (security hole, bug, annoyance).
Not only this, but I can start it w/ whatever args I happen to feel like..
`/usr/bin/imaginary-daemon --log-to=~eviluser/log --ignore-grant`.

b) The kernel doesn't care about executable types.  If it's told that
/usr/bin/sshd should be given the capabilities to open a port, it could
care less (barring binmisc_fmt) about whether that sshd file is an ELF
binary, a symlink, or a shell script (fun w/ IFS).

c) Complexity and security don't mix.  What would be done in cases
of chroots (relative file paths, whee)?  What about upgrades?
/usr/bin/sshd moving to /usr/local/bin/sshd (the admin has no patience
to wait for the latest sshd to get into stable ;) would cause quite a few
problems, for example.  Mount-points?  NFS?  Your model of trust is now
dependant upon the filesystem.  Filesystems were not designed for that
sort of thing.  This would add some nasty complexities..

> 
> (This is only half a solution, though: you're preventing them exploiting
> root by changing to use capabilities; what if they're out to exploit
> capabilities instead of merely `get root'? Still, it'd buy us some time...)
> 
> ~Tim
> -- 
> Newton and Adam, lost and found,            |piglet@stirfried.vegetable.org.uk
> The apple must fall to the ground           |http://spodzone.org.uk/
> 

If you're going to grant capabilities to a process (or user), you
must first have a rock-solid authentication method with which to make
sure they/it deserve that capability.  Path/filenames are not a decent
authentication method.  Uid isn't, either (as I keep telling friends
who use sudo w/ NOPASSWD.  ugh).  Traditional root is gained through
the use of a password; while there are many flaws w/ this method, it's
still better than relying IP, uid, name, or any other natural attribute
a process/connection/whatever may have.  sudo does this well by relying
on uid, the uid's password, command, and arg.. 

Ugh, sun's out, bedtime..

-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
        -- found in the .sig of Rob Riggs, rriggs@tesser.com