Weekly Edition
Return to the Security page
| |||||||||||||
Filesystem capabilities in Fedora 10Linux 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 all of 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
But, ping 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
article 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 determine SELinux policies, 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
CAP_NET_RAW. Hallyn's article also has code for a
capable_probe kernel module that can be used to see what
capabilities are
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 things like 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. (Log in to post comments)
Custom kernels and Fedora Posted Jan 8, 2009 6:58 UTC (Thu) by proski (subscriber, #104) [Link] It's strange that Fedora developers care so much about somebody using a kernel without some features, yet they make some many packages depend on their official kernel. Removing the kernel on Fedora 10 would remove nautilus and xorg-x11-drv-ati among other things.I think the opposite should be done. If somebody wants to use a self-compiled kernel, it's their responsibility to enable features Fedora depends on. On the other hand, users who have correctly compiled their own kernels should be able to remove the Fedora kernel without having to remove any userspace packages.
Custom kernels and Fedora Posted Jan 8, 2009 17:38 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
Logic fault.. concern over self-compiled binaries do not mean..binaries outside of the packaging system.
The nautilus situation is worth explaining.
nautilus as packaged requires gvfs-fuse. fuse has a versioned dep on the kernel. You can compile your own kernel...and package it as an rpm which still satisfies the packaging dependences for fuse or any other package which directly depends on the kernel. There are only a handful of packages in the Fedora repository which directly require the kernel package. And in each and most cases its a minimum kernel version specification. nouveau being the only different one.
For the F-10 release set, not including updates we have:
xorg-x11-drv-ati-0:6.9.0-54.fc10.i386
The real problem in the discussion isn't whether or not self-compiled kernels are being considered. The unspoken question is this, is there a better way to expose specific kernel settings in the packaging deps so that people generating their own kernel packages known exactly which options are required to keep functionality working. Obviously a kernel can be compiled without fuse support, but we don't have a way to express whether fuse is available in a packaged kernel or not. So as a result the very weak dep on minimum sufficient kernel version is used. My personal take on it is that these deps are somewhat historical artifacts which were introduced to make updating would work as expected when a new feature was added.
-jef
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 8:01 UTC (Thu) by asamardzic (guest, #27161) [Link]
I'm really unable to see any advantage of this and alike approaches over plain fixing program(s) in question to execute under superuser UID only during sequences of code where superuser privileges needed.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 8:46 UTC (Thu) by jamesh (guest, #1159) [Link]
The rationale goes that an application can't be exploited to do things it never had permission to do in the first place. The setuid bit gives an app a lot of permissions (even if it changes its effective UID when it doesn't need them).
In contrast, if the app only has the capabilities it needs you can only exploit those capabilities. So a bug in ping might only allow creation of raw sockets, but not bypass of file system permissions.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 13:05 UTC (Thu) by asamardzic (guest, #27161) [Link]
The code in a SUID application could at will switch, through setuid(2), between real and saved set-user-ID. So in this particular case, it should be possible to switch back to real user ID immediately upon program started and go this way until socket(2) call needed to open the raw socket. Just before this call, setuid() should be called to switch to saved set-user-ID (which means to switch to superuser privileges), and immediately after socket() returned the descriptor, setuid() should be employed again to switch back to real user ID (which means to return to executing as ordinary user). And that's the whole magic. Now, I'm pretty sure that things are not actually that simple in the ping source code, but still I fail to see what advantage this complicated capabilities mechanism could have over careful code examination, and applying proved techniques as this one I tried to describe above.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 14:27 UTC (Thu) by vonbrand (subscriber, #4458) [Link]
The problem is that malicious code that somehow subverted
Filesystem capabilities in Fedora 10 Posted Jan 9, 2009 6:53 UTC (Fri) by yvesjmt (subscriber, #38201) [Link]
I believe you're referring to seteuid(2) instead. The syscall you mentioned, setuid(2), makes a permanent change, because it sets the real and effective user IDs, and the saved set-user-ID.
Using seteuid(2) won't help. If the code can switch back to the saved set-user-ID and it gets exploited, it's rooted. No security added here.
If ping needed to open the raw socket only once, it could drop privileges permanently. But as we know ping needs to open sockets continuously.
> Now, I'm pretty sure that things are not actually that simple in the
Even if you do "careful code examination" when writing programs, that's not a replacement for good a security design. You'd still need other layers to protect from subtle issues[1].
One of the mantras of writing secure software is giving the least privilege necessary. That's what capabilities is about - though I confess I had never heard about them.
[1] I'd recommend this wonderful short book that covers this topic really well http://oreilly.com/catalog/9780596002428/
Filesystem capabilities in Fedora 10 Posted Jan 9, 2009 15:44 UTC (Fri) by jwarnica (subscriber, #27492) [Link]
If everything works well... then everything works well. You might as well not have the concept of user accounts, just have everything run at the same level. Just audit all your source code with proven techniques, and all is good. If everything works well.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 13:48 UTC (Thu) by elanthis (guest, #6227) [Link]
In order for a program to get superuser privileges it must already have superuser privileges. The alternative is to break apps up into two parts -- the frontend and the secured backend -- but that is neither practical for many projects nor actually a complete solution. If _any_ part of the program runs setuid then there is an opportunity for exploit. If _no_ part of it runs as setuid, then there essentially is no opportunity.
That is what capabilities are for. Give the program only what it needs and nothing else. You can take it a step further and split the program into frontend and backend pieces and give only the backend piece the capability necessary, too.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 14:34 UTC (Thu) by kilpatds (subscriber, #29339) [Link] It's not that hard to do: I've even got a library (PrivMan) to help. But it's still a good idea: it's usually a good idea to reduce the lines of code you have to audit/trust, and a good idea to replace less audited code with more audited code.
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 10:52 UTC (Thu) by ncm (subscriber, #165) [Link]
So, what changed recently that finally made capabilities usable?
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 14:29 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Perhaps more importantly, could somebody enlighten us on why the POSIX proposed standard was withdrawn? Known flaws, need more work than available hands, ...?
Filesystem capabilities in Fedora 10 Posted Jan 8, 2009 14:31 UTC (Thu) by kilpatds (subscriber, #29339) [Link]
Storing them on disk as part of an extended attribute, and then setting up the kernel to actually use the relevant extended attribute on disk.
What is so special about Fedora Posted Jan 9, 2009 22:43 UTC (Fri) by bollin (subscriber, #5582) [Link]
Filesystem capabilities in Fedora 10 Posted Mar 8, 2009 20:11 UTC (Sun) by druiloor (guest, #26069) [Link]
Slackware supports this as well (since v12.2)
$ lynx -dump http://www.slackware.com/changelog/current.php?cpu=i386 \
|
|||||||||||||