Fixing CAP_SETPCAP [LWN.net]

Fixing CAP_SETPCAP

Posted Nov 2, 2007 4:49 UTC (Fri) by zooko (subscriber, #2589)
Parent article: Fixing CAP_SETPCAP

"... trying to come up with ... sensible security solutions ... casting about ..."

Perhaps we should start with some sensible security problems. What problems are we trying to solve?

One of my problems is that I don't want to give an application all of my privileges when I run it, but I still want to give it some of my privileges. For example, I would like to download a nice new game off the Internet, extend to it my privilege to read and write in ~/.gamesave/newgame, and the privilege to open net connections to specified hosts, and the privilege of doing graphics and I/O in a constrained screen (e.g. a different X server, a different virtual terminal), but not give it the privilege of reading or writing any of my other files, performing other networking, continuing to run after I have shut it down, nor any other privileges.

Is this the same kind of problem that these security modules I keep reading about are trying to solve?

plash -- the Principle of Least Authority Shell seems like a good step in the right direction.

Note that plash is inspired by the theory of capability access control (although not by the "POSIX capabilities" that were the topic of this article.)

(Log in to post comments)

Fixing CAP_SETPCAP

Posted Nov 2, 2007 6:16 UTC (Fri) by njs (subscriber, #40338) [Link]

On that note, I actually agree with the article that "a capabilities-based distribution would
be interesting to see" -- except with, you know, real capabilities :-).

Unix has them, after all -- fds are exactly capabilities.  (A pipe is a kernel-space ring
buffer with two facets, etc.)  The model is a little inelegant because you have normal
numbered fds, the quasi-fds for "current directory" and "root directory" (all the syscalls
that take filenames are effectively calls against the interface these fds provides), and the
vast number of syscalls that are available to every process provides a little more exposure
than one would like... (kill(2), for instance, is annoying).  But these seem mostly solveable,
and in these days of bind mounts, FUSE, containers, etc., one could do pretty credible
POLA/capability-style containment with the stock Linux kernel and a custom userspace.

Plus it seems worthwhile to try, because capabilities are the best chance for surviving worms
and all the other wonderful conveniences of the modern internet, but so long as they only live
in pure-research OSes they aren't going anywhere.  Building on Linux gives you its existing
userspace to use as a base, and lets you move quickly to dealing with the real problems of
building a practical system that one can deploy, administer, etc.  (Eros is very cool, but how
the heck could one ever practically administer or even understand a system whose whole state
is a blob of gigabytes of memory tied together willy-nilly by pointers?)

Fixing CAP_SETPCAP

Posted Nov 2, 2007 6:42 UTC (Fri) by njs (subscriber, #40338) [Link]

Err... ObOnTopic: Building a system like I describe is much easier given the existence of
CAP_SYS_CHROOT.  (Though another option would be to eliminate the root dir entirely by
chrooting everything to a designated unreadable/unwriteable/empty directory, and just using
openat() etc all the time.  ...Too bad there's no execat().)

Fixing CAP_SETPCAP

Posted Nov 2, 2007 15:09 UTC (Fri) by zooko (subscriber, #2589) [Link]

NJS:

Your idea sounds like Adam Langley's master's thesis:

http://www.imperialviolet.org/binary/pucs.pdf

Fixing CAP_SETPCAP

Posted Nov 2, 2007 23:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Is this the same kind of problem that these security modules I keep reading about are trying to solve?

I think it is, but a similar problem is equally important: you're running code which is essentially trusted (maybe you wrote it yourself), but you know it might be broken. While this program isn't supposed to erase log files, a cracker might exploit a bug and make it try. So you'd like a safety net, immune to any bug that might exist in that program.

In classic Unix, you'd have a problem establishing that safety net if the program must be able to scan all the files on the system, because the same privilege that lets you read all the files (superuser) also lets you write to them.

The Linux privilege classes ("capabilities") don't seem well chosen, though. 6-10 of them (depending on other system properties) are equivalent to all the rest -- i.e. having one allows you to get the rest. And most of the privileges you'd like to separate are piled into one: CAP_SYS_ADMIN.

Fixing CAP_SETPCAP

Posted Nov 4, 2007 4:10 UTC (Sun) by nlucas (subscriber, #33793) [Link]

The general use of CAP_SYS_ADMIN all around the kernel is what makes me doubt of any new
capability system extensions to what exists now.

I'm no security expert, but can't understand how they can overcame that without a major
overhaul all around the kernel code.

I see this new features as nice things to help secure a system, but this all seem just more
"hacks" around the fact there isn't any "grand scheme" for security well thought (I mean, in a
modern way, because we all know traditional UNIX security way is just obsolete).