File-based capabilities [LWN.net]

The capability model has some real appeal. It replaces the "all or nothing" security model inherent in the root account with a set of fine-grained permissions describing exactly what a given process can do. Linux has supported capabilities for years, but this feature has seen little use for a number of reasons; see this article from last September for more general discussion of capabilities.

The fact that capabilities have not been used much has not stopped developers from trying to improve the feature. The latest attempt is the file capabilities patch by Serge Hallyn. This patch allows a system administrator to add specific capabilities to an executable file; when that file is executed, the process's capability masks will be set to the capabilities associated with the file. This feature thus functions somewhat like the file setuid bit, but with finer control.

On the kernel side, file-based capabilities work through the extended attribute mechanism. Capabilities are added to a file by setting a attribute named security.capability; the value of the attribute will be this structure:

    struct vfs_cap_data_disk {
	__le32 version;
	__le32 effective;
	__le32 permitted;
	__le32 inheritable;
    };

The version field holds the current capability version; the other three hold the expected capability masks.

There are a few interesting features of this implementation:

One might wonder what keeps the user from just setting an extended attribute and obtaining whatever capabilities might be desired. While setting extended attributes is not a privileged operation, setting attributes whose name starts with "security." is. So, unless the user has root privileges, he or she will not be able to set capability attributes. (For the curious, the other restricted attributes are trusted.*, which only root can query or change, and user.*, which, in some situations, can only be changed by the owner of the file).
The capability masks stored with the file completely overwrite the process's current capabilities. So, if the root user executes a file with capabilities set, it may run with fewer capabilities than it would have otherwise had.
The setting of capabilities is done outside of the check for filesystems mounted with the nosuid option. This behaviour would appear to open the system up to attacks via a removable filesystem created on a different system.

A set of user-space tools exists for working with file-based capability masks; see the filesystem capabilities page for downloads, documentation, and examples.

Before celebrating the arrival of file capabilities, it is worth asking whether system administrators really need another 31 (at last count) permission bits - multiplied by three separate capability masks - to manage on every executable file on the system. It can be hard to keep file permissions bits in proper order even without capabilities. A full capability-based system would approach SELinux in complexity, and may thus be beyond the ability of most people to manage. But one could use this feature to assign restricted capabilities to programs which currently run setuid root. In many cases, root privilege is only need to bind to a low-numbered socket, adjust the system time, or perform raw I/O. Restricting a program to its needed capabilities should reduce the changes of that program being used to do something unexpected.

(Log in to post comments)

File-based capabilities

Posted Dec 1, 2006 18:44 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

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

Posted Jan 27, 2008 17:26 UTC (Sun) by AnswerGuy (guest, #1256) [Link]

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

Posted Oct 14, 2007 20:42 UTC (Sun) by garloff (subscriber, #319) [Link]

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

File-based capabilities

Posted Dec 1, 2006 19:10 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

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.

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

Posted Dec 6, 2006 20:02 UTC (Wed) by zooko (subscriber, #2589) [Link]

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