From: Joseph Gooch (mrwizard_at_dok.org)
Date: Wed 12 Nov 2003 - 02:47:46 GMT
> -----Original Message-----
> From: linux-privs-discuss-admin_at_lists.sourceforge.net
[mailto:linux-privs-
> discuss-admin_at_lists.sourceforge.net] On Behalf Of Chris Wright
> Sent: Tuesday, November 11, 2003 8:11 PM
> To: Linas Vepstas
> Cc: vserver_at_daffy.hulpsystems.net; linux-privs-
> discuss_at_lists.sourceforge.net
> Subject: Re: [Linux-privs-discuss] Capabilities & capability tools in
> Linux
>
> > that there should have been a pair of bits: LOWERPCAP and
> > RAISEPCAP, instead of SETPCAP. Seems to me that LOWERPCAP, by
allowing
> > one process to take away the caps of another, is reasonably safe
> > and useful. So I was trying ask if you/other gurus see something
flawed
> > with this line of reasoning.
>
> Even this is a trusted action. A LOWERPCAP privileged process could
> quickly disable a process by taking away it's needed, e.g.
CAP_NET_BIND,
> privilege. Perhaps it's just a DoS, but it's not a no-brainer to give
> your proposed priv away. Guess I'd wonder if there's not another way
to
> achieve this? Also, if you look at the draft, you'll see a SETFCAP
(not
> raise and lower). For better or worse, I imagine SETPCAP was intended
to
> be somewhat analogous, and useful since there was not filesytem
support.
> Sorry, I don't have full history knowledge of the project.
I direct your attention to the sendmail exploit... it was capabilities
based. All you had to do was remove sendmail's ability to do a setuid()
call, through the inheritable bits in the spec. You're left with a
setuid bit program running as root, that cannot drop its own privs!
Find a sendmail exploit, that normally wouldn't yield root, and now you
have a problem. Taking away privileges can be just as dangerous as
assigning additional privs.
The big problem with capabilities from my POV is that there hasn't been
a distribution made that uses them. The big problems with the model
include 1) It really *needs* filesystem capabilities to take off...
otherwise, you still have to have a process, uid, or some other program
that is a 'superuser' who determines who can do what. That's still a
point of failure. Even with filesystem capabilities, who sets the
filesystem capabilities :) The idea is to get away from the superuser
concept, and instead give people SETFSCAP rights.. which doesn't imply
mucking around with existing processes! And unless you have the right
to modify files you don't own (FOWNER), you're stuck to what you can
modify.
2) A true capabilities model would have no root user. UID 0 is a normal
user just like everyone else. Unfortunately, decades of UNIX mentality
goes against things like this, because of things like assuming if we're
root, setuid will work... assuming uid 0 means full privs, assuming that
files owned by root are untouchable... So, the kernel is written to be
compatible with the unix security model. Root processes get all privs
on execution... so even if a process gives up its privs, any process
spawned by it as a root user gets them again, automagically. Same with
normal users, a setuid drops all caps even if they're adjusted
beforehand. (this 'emulation' is what will be written into a module in
2.6 I'm guessing...)
If a distribution were made using the filesystem capability patches that
use EXT2 extended attributes (I have no clue how ext3 fits in), it would
require the extensive rewriting of most of the software out there
today... assumptions that have held for years would no longer be sane.
It's not impossible, it would be a chore for sure... but the resulting
distribution would be really secure :)
NONE of this precludes an individual process from dropping its own caps!
In the case of bind9, you patch the source, and you're golden. Things
like proftpd do this with a security module. 2.4 introduced a prctl()
call that allows for keeping dropped privileges... it eliminates enough
of the emulation code that modifying applications to drop their own
privs is possible. I did a couple patches to source code way back when
to implement these types of changes... tcpdump, wu-ftpd, apache, bind8,
ping, traceroute,etc.. I targeted suid apps and net daemons. Things
like removing all but CAP_NET_BIND, CAP_NET_RAW.... things like
removing CAP_CHROOT after putting a process in a jail... good stuff.
SuSE has a program called "compartment" that does caps as well as
chrooting and setting uid/gid of processes, and given a small patch to
set prctl(PR_SETKEEPCAPS,1) before calling the process, it works. I'm
not sure where the development of that has gone.
In the end, it seemed like it was more work to maintain than the
benefits provided.
That's my rationale anyway.
Joe
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver