LWN: Comments on "A bid to resurrect Linux capabilities"

A bid to resurrect Linux capabilities

cras — Mon, 25 Sep 2006 08:21:49 +0000

But locking down ptrace() might be a good way to prevent an exploited connection from messing with another one in forked servers. I think the only other way would be to bind as root, then setuid() to one of a pool of uids or something...I hope no one's doing that

A pool of UIDs is not required, just doing setuid() after exec() will make the kernel think the process is in "setuid state" and won't allow other processes ptrace it.

A bid to resurrect Linux capabilities

slamb — Fri, 22 Sep 2006 08:24:53 +0000

This patch uses some of those new bits from the outset for a set of "regular capabilities" which all processes are normally expected to have. These capabilities include the ability to use fork() or exec(), the ability to open files and to write to files, the ability to use ptrace (), and the ability to increase privilege by running a setuid program.

Woo! I'm glad to see someone do this. I've long thought this was the best way to take advantage of capabilities. I even wrote a crappy patch to OpenBSD long ago, which fortunately for the world never made it beyond my system.

Many of the regular capabilities can easily be used to gain full root access. (Though I thought that about pcap, and omnipresent ssh has proven me wrong.) But locking down ptrace() might be a good way to prevent an exploited connection from messing with another one in forked servers. I think the only other way would be to bind as root, then setuid() to one of a pool of uids or something...I hope no one's doing that.

A bid to resurrect Linux capabilities

jbailey — Fri, 15 Sep 2006 09:27:04 +0000

I suspect yes. The problem in that scenario is that you still have to go to full priviledges first. So while the attack vector is very small and unlikely, it's not non-existant.

If we had fullsystem-based priviledge raises beyond just SUID/SGID, I suspect it would be taken up quite quickly by distros.

Tks,
Jeff Bailey

capability inheritance works fine in 2.4

sweikart — Fri, 15 Sep 2006 03:10:01 +0000

> But the kernel has also never implemented capability inheritance
> - what happens to the capability bits when a process executes a
> new program - in a correct manner.

Actually, the inheritance behavior in the 2.4 kernel worked fine for me. The GPL'ed Martus Server software (available near the bottom of the Martus download page) implements my custom security model based on Linux capabilities. I wrote a caps command that root can execute to change the capabilities of other processes (it sets CAP_SETPCAP in the capability bounding set by poking /dev/mem, then forks and execs to acquire CAP_SETPCAP, then clears CAP_SETPCAP in the bounding set, then applies the user-specified capabilities to the user-specified processes). I wrote a few paragraphs describing the semantics of the 2.4 kernel's capabilities, based on my experimentation. My /etc/rc.d/init.d/martus startup script sets CAP_SETPCAP (plus a subset of the normal capabilities) in the inheritable set of the sshd listener and init, and then clears all capabilities in the bounding set (and in other processes running at startup time). So, a human that logs in gets (a reduced set of) the normal capabilities, but the application-listeners have no capabilities.

I even use my caps command to give CAP_NET_BIND_SERVICE to a non-root java, so it can open a privileged port (after which I remove CAP_NET_BIND_SERVICE).

But, all this was a lot of work. I'll just use SELinux when I move the software to the 2.6 kernel.

-scott

A bid to resurrect Linux capabilities

jzbiciak — Thu, 14 Sep 2006 22:13:04 +0000

...in which case a "default per-mount permitted capabilities" sounds useful.

A bid to resurrect Linux capabilities

giraffedata — Thu, 14 Sep 2006 19:18:59 +0000

I've always wondered why the security conscious world hasn't paid more attention to using Linux capabilities. People go to great lengths to change UID and re-exec things and create setuid helper programs and such to reduce the amount of code that has privilege, but Linux capabiities do the same thing (by design, that is) and get ignored.

I liked the idea so much for protecting my own systems that I made a few small fixes to Linux 2.4 years ago to make capabilities work, wrote the missing administration tools for them, and have used them extensively. Hardly anything runs as superuser on my systems.

For the missing setuid function (attaching capabilities to files), I used an idea that was posted in a comment to an LWN article on the topic a few years ago: Rather than mess with exec and filesystem code, I wrote a simple executable interpreter (those are modular in Linux; the ELF interpreter is one example). Execing a privilege-raising program is two steps: user execs a setuid file which is in "capx" format, and that file sets proper capabilities then execs the regular non-setuid ELF file.

It will be nice to have a clean, working implementation in mainstream Linux, but I wonder if anyone will use it, since they haven't cared so far. I'm the only person I've ever known to use capabilities.

A bid to resurrect Linux capabilities

nix — Thu, 14 Sep 2006 18:58:53 +0000

I was thinking that it's rare compared to the number of programs installed
in /usr/bin: but then if the user's compiled a program herself she's a lot
more likely to run it than a given random binary in /usr/bin...

A bid to resurrect Linux capabilities

kfiles — Thu, 14 Sep 2006 17:35:35 +0000

I'm not sure I agree with the premise that no Linux distribution has shipped with active capabilities support, or that current capabilities support is inherently unusable due to the lack of inheritance.

For many years, I've used the highly-secure EngardeLinux distribution from Guardian Digital, which shipped with LIDS (http://www.lids.org) installed and enabled by default. Now, LIDS development is mostly bug-fixing at this point -- it's not pushing cutting edge features. However, for a manageable Mandatory Access Control system utilizing capabilities, it's quite nice. Like SELinux, it uses centralized ACL configuration rather than file attributes, which makes it a better fit for distributions than for package owners (See, e.g. AppArmor, as a solution that enables each package to ship its own ACLs).

Thanks,
--kirby

Editorial fixes...

corbet — Thu, 14 Sep 2006 14:51:42 +0000

Your editor was in a hurry, trying to get things done before traveling to Europe for the Wizards of OS. Thanks to the magic of free hotspots in Potsdamer Platz, the mistakes are now fixed.

A bid to resurrect Linux capabilities

jschrod — Thu, 14 Sep 2006 11:35:51 +0000

Mind you it's quite rare to run binaries over NFS these days.

I don't agree with that opinion. A common use of NFS is to provide netwide home directories. If a user installs any program privately, or if she develops programs, executables will be run from this NFS share. And IMNSHO this scenario is not "quite rare".

Cheers, Joachim

A bid to resurrect Linux capabilities

nix — Thu, 14 Sep 2006 10:00:42 +0000

Well, a capability-based system would have no trouble keeping anything in sync with the capability masks on files, because there *is* nothing to keep in sync. The relabelling operation consists (very roughly) of tracking down the xattrs on labelled files and bringing them in sync with what's defined in the SELinux config files: no analogous operation exists if xattrs are the only storage representation, just as you don't need to wait for ages while permissions are synched with anything when you boot :)

(The interaction of all this with Samba and NFS-without-xattrs is interesting: the standard capability inheritance model is totally broken in that situation. Mind you it's quite rare to run binaries over NFS these days.)

Editorial fixes...

alonz — Thu, 14 Sep 2006 07:17:08 +0000

(Is our esteemed editor becoming tired? ;-) )
Third paragraph: "the kernel has also never inherited capability inheritance" should be "the kernel has also never implemented capability inheritance"
Sixth paragraph: "implementation of priority inheritance" should be "implementation of capability inheritance"