LWN: Comments on "File-based capabilities"

File-based capabilities

AnswerGuy — Sun, 27 Jan 2008 17:26:06 +0000

He said "things" not people.

With file based capabilities it's usually the case that you trust the intentions of the user,
and the programmer who wrote the code.  But you're trying to limit the damage that processes
running this code can do to the rest of the system (which giving them enough power to do their
job) --- in the all-too-likely case that the program can be subverted in some way (buffer
overflow, printf error, stack overflow in regex parsing, et cetera, ad infinitum, ad nauseum)

Personally I still thing the cleanest most understandable way of accomplishing this sort of
goal has been the systrace patches by Niels Provos.  They make perfect sense to anyone who has
ever had to deal with packet filtering and they are the only approach I've seen that would
allow a normal user to effectively limit behavior of software.  (One could imagine a user
creating systrace configurations to prevent his or her browser from accessing specific
document trees and other files, for example.  The implications of this are far more
significant than one realizes in an era when many of us are seriously considering locking our
browsers --- and perhaps our MTAs --- into their own virtual machines to protect the rest of
our home directories therefrom).

JimD

File-based capabilities

garloff — Sun, 14 Oct 2007 20:42:41 +0000

AppArmor should do what you need, then.
You can assign capabilities to executables with it.

POSIX "capabilities" are fatally flawed in a way that real capabilities are not

zooko — Thu, 07 Dec 2006 19:33:40 +0000

Follow-up to self for editing: I wrote "increased granularity of protection", but I meant "finer-grained", rather than "larger-grained". I hope the meaning is now clear.

POSIX "capabilities" are fatally flawed in a way that real capabilities are not

zooko — Wed, 06 Dec 2006 20:02:13 +0000

Please note that POSIX "capabilities" and Linux "capabilities" are a different security model from the model called "capabilities" among security researchers. It is unfortunate that because of this naming collision that the fatal flaws in the POSIX model will be held against the original capability model, which doesn't share these flaws.

A good example of such a fatal flaw is that in so-called "POSIX capabilities", increased granularity of protection implies increased cognitive load on the user/programmer/administrator. Corbet wisely questions the usefulness of this in the article.

By contrast, in the real capabilities framework such as originally published by Dennis and van Horn, and as implemented in EROS and in the E language, as well as other implementations, increased granularity of protection (compared to traditional Unix access control) comes with reduced cognitive load on the user/programmer/administrator. This may sound contradictory at first, but it is possible because the real capability framework takes advantage of information that is already present but that the other frameworks do not use to advantage. That is, the naming information.

All users, programmers, and administrators have to use names for things in order to organize their own work, and the real capability framework uses that naming information to bootstrap fine-grained, high-assurance protection which is intuitively meaningful to users and requires minimal "extra work". For the so-called "POSIX capabilities" framework (just like the ACL framework and others), adding protection requires adding extra work, which is never going to fly.

For more information, see the section on POSIX capabilities in http://zesty.ca/capmyths. If that section doesn't make sense to you by itself, the try reading the rest of the document up until that section. ;-)

Regards,

Zooko

File-based capabilities

giraffedata — Fri, 01 Dec 2006 19:10:38 +0000

The article misses the point that Linux capabilities were designed from the beginning to have this. It is not a new idea; it's just completing the job. (It hasn't been completed before now because people just haven't been interested in fine-grained capabilities).

The capability masks stored with the file completely overwrite the process's current capabilities.

However, this flies in the face of the original design. I know the meanings of the 3 capability sets is hard to grasp, but it looks like someone failed here. A file's permitted set is supposed to be those capabilities that get added to a process by virtue of execing the program in that file (the traditional effect of setuid 0). A file's inherited set is supposed to be those that a process is allowed to keep even though it execed that program (it removes capabilities -- the traditional effect of setuid non-zero).

A process also has 3 permission sets that are unfortunately identically named. Simply setting those masks from an attribute of the exec'ed file isn't nearly as useful.

The setting of capabilities is done outside of the check for filesystems mounted with the nosuid option.

This is dangerous as all hell. If it goes in this way, they had better make sure this entire function is disabled by default, or a bunch of systems are going to be compromised by installing the new kernel code.

Here's some interesting information from someone with experience in Linux capabilities (me):

I analyzed them all once and found that 6 of them are equivalent to all of them (having any one allows you to get all the others). They're still effective against accidental damage, but not against intentional damage.
Most privileges are piled into one capability: SYS_ADMIN.
The most frequently useful one (NET_BIND_SERVICE) lets you bind a reserved port number and nothing else, but the problem of programs that have setuid 0 just for that can be solved more cleanly by having separate program bind the port and pass the file handle to the untrusted program.
The setuid 0 programs that have had the scariest security bugs in them are usually the ones that can't be limited to weak capabilities. E.g. SSH server, file server, mail server.

File-based capabilities

giraffedata — Fri, 01 Dec 2006 18:44:59 +0000

I don't think capabilities will change that.

I used to use an operating system that had fine-grained capabilities and system administrators were usually not willing to let anyone other than those who qualified for _all_ of them have _any_ of them. I.e. it's a binary thing -- either you're in the trusted group or you're not.

You can sort of see their point: fine-grained capabilities multiply complexity, and complexity generates ways to make mistakes.

I use Linux capabilities extensively (using local modifications to Linux), but it's always for things that, if I didn't have capabilities, I would be willing to do with superuser.

File-based capabilities

skissane — Fri, 01 Dec 2006 00:42:05 +0000

I cannot wait enough for this to be rolled in.
This is a frequent issue for me -- if you've ever had to deal with system administrators that don't like making things suid root, you'll know what I mean...

File-based capabilities

jospoortvliet — Thu, 30 Nov 2006 13:14:43 +0000

indeed. i guess it wouldn't be very hard to apply certain basic
restrictions, making the system more secure, without hampering it's use.

i do find it hard to grasp the (details of the) difference between SElinux
(and friends) and these capabilities, tough. as i read about it, i wonder
why SElinux couldn't use these capabilities?

File-based capabilities

NAR — Thu, 30 Nov 2006 10:10:19 +0000

A full capability-based system would approach SELinux in complexity, and may thus beyond the ability of most people to manage.

I guess it may, but shouldn't this kind of things be managed by the distributors? Shouldn't rpm/dpkg set these bits up properly?

Bye,NAR