Linux capabilities have been around for a long time, but they are finally
starting to get to the point where they can actually be used. There are
still no mainstream distributions that make use of them, but Fedora 10 has
the requisite functionality available, as Ulrich Drepper recently pointed out in a blog
posting. There are now systems available for administrators to begin to
try out capabilities to see what advantages they offer.
Note that this article concerns Linux/POSIX capabilities and not the other
security approach of the same name.
The canonical test program for capabilities seems to be ping; that
is what Drepper used, as did Chris Friedhoff in his capabilities
documentation. Currently in Fedora 10, ping is a setuid-root
program as it needs privileges that normal users do not have. Removing the
setuid bit with
chmod u-s /bin/ping
results in normal users getting the following error:
ping: icmp open socket: Operation not permitted
can be left without the setuid bit, by proper
application of capabilities.
By using the setcap command, a root user can give the required
capabilities to the ping program. These get stored as extended
attributes (xattrs) in the filesystem and queried by the kernel when filesystem capabilities are
enabled. It should be noted that not all filesystems support xattrs, but
for those that do, setcap will add the "capability" attribute
with a 20-byte value representing the capability information.
The capability required by ping is CAP_NET_RAW, so an
administrator who wants to have a non-setuid-root ping must do:
setcap cap_net_raw=ep /bin/ping
This sets the CAP_NET_RAW
bit in both the "effective" (e) and
"permitted" (p) capability sets. These two sets, along with the
"inheritable" set, govern the capabilities that a process has or can set.
Serge Hallyn's developerWorks
is a good reference for how those sets interact.
But, how does one find out what capabilities a particular program needs?
In some ways similar to the audit2allow method sometimes used to
one can look for permission denied errors as Friedhoff describes:
$ strace ping localhost 2>&1 | grep EPERM
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)
In this case, ping
tried to open a raw socket which requires
. Hallyn's article also has code for a
kernel module that can be used to see what
requested. As with the SELinux method, one must be careful that the
capabilities requested are actually reasonable for the program's task
before granting them.
Now that capabilities are available, folks have started to wonder when
ping will have their setuid bit removed in standard
distributions. Panu Matilainen asked
on fedora-devel: "Are we ready to start considering moving away
from SUID bits to
capabilities, in Fedora 11 maybe?" The answer in the resulting
thread seems to be "no", mostly because there is concern about folks
building their own kernel without support for capabilities. It is a bit of
a weak argument because Fedora depends on any number of kernel options.
Drepper is characteristically blunt: "That's nonsense since there
are many other options we rely on and which can be compiled out."
Other distributions may handle things differently, though, so we may see
Linux-capability-based systems elsewhere. For now, administrators can turn
off setuid and instead set capabilities on programs in Fedora 10,
"unfortunately you have to do it every time the program is updated
again," Drepper notes. Capabilities were originally added to Linux
in the 2.1 kernel series, around ten years ago, so it is nice to see them
finally getting to the point of usability for regular users and
administrators. It will be interesting to see where things go from here.
to post comments)