Inheriting capabilities

Linux capabilities have long been seen as a way to avoid setuid programs, though the reality hasn't really lived up to the hope. While partitioning root privileges into distinct, fine-grained permissions has a lot of conceptual merit, the implementation suffers from a number of shortcomings that make it difficult to, say, use capabilities to allow ping and other utilities to run without being setuid root. Actually using capabilities has always been complex, and there are some fundamental limitations that are sometimes worked around in out-of-tree patches. A recent discussion on the linux-kernel mailing list looks at one of the limitations of the capabilities model, with an eye toward eliminating it.

Under the current model, processes cannot easily pass their capabilities to another program through an execve() call in the same way that other privileges are inherited. Christoph Lameter posted a patch that would allow administrators to specify which capabilities should be inherited by programs started by execve(). The idea is to allow privileged, non-setuid-root programs to spawn other programs with a limited set of privileges—exactly the kind of facility that capabilities are supposed to provide.

We have looked at Linux capabilities multiple times over the years, often in the context of a new attempt to fix some of the deficiencies in the existing Linux capabilities model (which is derived from a defunct POSIX effort). For example, file-based capabilities were added to use the extended attributes (xattrs) on program files to store capability information so that those capabilities were granted to programs when they were executed. Adding that allowed the CAP_SETPCAP capability to return to its original meaning and provided a way for administrators to grant capabilities to individual programs (rather than running processes). There are other problems we have noted; in some sense, this article is a continuation of that trend.

Lameter described his use case in the patch. He runs a network stack in user space that requires privileges for raw network access, but also may run arbitrary binary programs. He would like to restrict what those programs can do, but needs them to have a certain subset of root privileges. That could be done using setuid programs, but he would like to restrict those programs so that they don't get all of root's privileges.

A 2006 LWN article that Lameter referenced in his posting describes the underpinnings of capabilities. In particular, it looks at the different capability sets and how they are combined to determine which capabilities a process has.

This first patch from Lameter provides a way for an administrator to globally specify which capabilities should be inherited across execve(). Capability numbers could be written to a sysfs file, which would cause those capabilities to be inherited by any new program if the caller of execve() possessed them. He has been using a form of the patch in production for the last six years, but would like it (or something that solves the same problem) to go upstream, so that he doesn't need to continue carrying the patch in his kernels.

The usual way to make a binary run with some capability is to put that capability in the "permitted" and "effective" sets of the binary using the file capabilities xattrs. Doing that makes those binaries always have those capabilities, however, which may not be desired—especially for system binaries. Without putting file capabilities on many different binaries throughout the system, there is no way to pass CAP_NET_RAW (or others, such as CAP_NET_ADMIN and CAP_SYS_NICE) down to child processes or new programs started with execve(). Also, given that there is scripting (and LD_PRELOAD) involved in Lameter's use case, it would be necessary to give script interpreters (e.g. Bash, Python) whichever capabilities the scripts need—something that is not likely to lead to a more secure system.

It looks like a fundamental limitation of the Linux capabilities model, but is hardly the first. Capabilities bits have been arbitrarily chosen by kernel feature developers over the years, without much in the way of coordination. That has led to grab-bag capabilities like CAP_SYS_ADMIN that are effectively equivalent to root (though there are others where that is also true). Whatever can be said about the Linux capabilities feature, coherence in its design and implementation are not particularly evident.

But people who want to use the feature keep running up against barriers to doing so. As Serge Hallyn, one of the developers of capabilities, lamented, it is still not possible to make ping use capabilities (rather than setuid) by default. That's because some filesystems don't have support for xattrs; it's also true for some of the tools, such as older versions of tar and current versions of cpio (though work is being done to change that).

But the global nature of the inheritance setting in Lameter's patch set was not popular. Both Hallyn and Andy Lutomirski suggested ways to make it a per-process or per-user-namespace setting. Hallyn suggested adding an "ambient inheritable" set that would be combined with the inheritable set in a way that is somewhat analogous to the capability bounding set. Lutomirski thought that a single bit could be used to say that all files should be considered to have a full set of capabilities in their inherited set, which would basically have the same effect.

But Casey Schaufler objected to the idea that Lameter's use case was reasonable from a security perspective: "You're getting into pretty sketchy territory using that kind of a programming model in a security enforcing environment." Though he also responded to Lameter's claim that there is a "capabilities mess" that needs to be cleaned up:

There was some discussion of ways that capabilities could be improved but, as Lutomirski noted, none of that addressed the problem at hand: "If I hold a capability and I want to pass that capability to an exec'd helper, I shouldn't need the fs's help to do this." There was general agreement, though Hallyn pointed out that using the filesystem to place capabilities on binaries is how POSIX capabilities work.

One interesting side note from the discussion is that Lameter is not the only one to use inheritable capabilities in production: the MeeGo-based N9 phone from Nokia did as well.

After that discussion, Lameter shifted gears, posting an RFC patch to implement Hallyn's suggestion of an ambient capability set. That was met with a couple of objections on some of the specifics. To start with, adding capabilities to the ambient set should not enable capabilities that are not in the permitted set of the process, Lutomirski said. He also suggested that adding capabilities to the ambient set should require more than just having the CAP_SETPCAP capability. Requiring PR_SET_NO_NEW_PRIVS (see this article and Documentation/prctl/no_new_privs.txt for more information), so that execve() could not add any additional privileges, would make him more comfortable. But that "would make the patch pointless" because programs that require more privileges (e.g. setuid root programs) need to be run sometimes, Lameter said.

Given Lameter's use case, requiring PR_SET_NO_NEW_PRIVS would seem to be a non-starter, but he has addressed the other complaints from Lutomirski and Hallyn in his V1 ambient capability set patch. In that version, only capabilities that are permitted can be added to the ambient set. In addition, processes can clear their permitted set and be sure that no new capabilities will be granted to children or programs run via execve() based on the contents of the ambient set. That was one of the main concerns expressed about the RFC patch.

As was noted in the threads, there are a number of barriers in the way of using capabilities on Linux systems. They are complex to reason about, have an API that is difficult to use, and have been inconsistently applied over the years. All of that is unfortunate, but any movement to remove capabilities and start over, as was suggested, is pretty unlikely to gain any traction. For good or ill, capabilities are part of the kernel ABI and are thus likely to be with us "forever". Changes like the ambient set may not reduce the complexity at all, but may help provide a more usable capabilities system going forward.