Re: Got root?
Andres Salomon <dilinger@mp3revolution.net> writes:
> > 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),
Disclaimer: I've never worked with capabilities explicitly. :)
> 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.
This is exactly the point in my bottom paragraph before.
> > 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?).
This is all talk of `root' though. Root covers and causes a multitude of
sins - if you can't do it as root then you're writing to a squashed NFS
filesystem and that's it. I see these capability things as adding
granularity to `just do it as root' and `I must crack root'.
> 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).
Both of these can be fixed within reason by adding users for each daemon
(hey, I know a distro that does that ;) and having the proposal check:
if user is in list of designated uids
if file is a recognized file
if file has correct ownership same as the favoured user
THEN it may execute it *as* that user (strictly no setuid() calls required)
and allow the optional extra ability to bind to low ports.
One of the core things I've seen in security circles is `only allow what
you need'; if you have more granularity you can map ACLs onto needs more
precisely rather than saying `just be root'.
> c) Complexity and security don't mix. What would be done in cases
> of chroots (relative file paths, whee)?
I don't see a problem with that. If it were up to me, I'd keep absolute
paths in a config file, grant the ability to call chroot() and have done.
> 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 ;)
`apt-get source' pointed against unstable? ;)
> 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..
A *lot* of things boil down to the security of the filesystem. You can
cover your butt in many ways but you have to ask `how could they create a
file /usr/sbin/sshd owned by ssh.ssh if I've not already cracked the box?'.
> > (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...)
>
> 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..
Agreed in pricniple; I'm not qualified to dictate specifics.
> Ugh, sun's out, bedtime..
Wish I could say the same as well!
~Tim
--
12:54pm up 1 day, 13:20, 9 users, load average: 0.19, 0.45, 0.52
piglet@stirfried.vegetable.org.uk |All I see, All I know
http://piglet.is.dreaming.org |Is touching the sacred earth
And warming the hallowed ground |
Reply to: