Instead of using setuid programs, the goal for the future is to use fine-grained capabilities. For example, here is /bin/ping:
$ ls -la /bin/ping
-rwsr-xr-x 1 root root 35680 2009-11-05 00:41 /bin/ping
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
…
$ sudo setcap CAP_NET_RAW=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
…
$ dmesg | tail -n1
[212275.772124] warning: `/bin/ping’ has both setuid-root and effective capabilities. Therefore not raising all capabilities.
The best part is that the kernel will choose the set of least privileges when both setuid and capabilities exist. Easy way to transition!
© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Kees, this is outstanding! I’ve envisioned[1] for sometime a mainstream distro that will eventually ship without suid root applications. Granted that was a _long_ time ago, but it was really exciting once Serge Hallyn sent the pull request for that patch.
Your work on _proactive_ vs reactive security is one of the reasons I stick with Ubuntu.
[1] https://wiki.ubuntu.com/Security/Investigation/Setuid
Comment by Jeff Schroeder — February 9, 2010 @ 5:46 pm
Well, thanks! But, don’t get too excited; we’re not there in Lucid (there’s no packaging support for this in Ubuntu yet), but I’m quite interested in getting it working. At the very least, we can document all the caps that need to be set for a default install.
Comment by kees — February 9, 2010 @ 8:01 pm
Can you explain how this will be supported by distributions like Debian? I assume we can’t add filesystem capabilities to the files stored inside the data.tar.gz inside the .deb?
Comment by someone — February 9, 2010 @ 9:52 pm
fscaps are just extended attributes, so in theory, it could be stored by cpio/tar/etc. What I’m designing would be for dpkg and would be handled similar to normal permission bits, including something like a /var/lib/dpkg/statoverride file for local modifications, etc. I hope to have some proof-of-concept emailed to the dpkg devel mailing list soon, but we’ll see what time permits.
Comment by kees — February 9, 2010 @ 11:02 pm
Was there progress on this?
Comment by Philipp Kern — July 6, 2010 @ 12:40 am
@Philipp: unfortunately not. There are several blockers still, not the least of which is tar itself: https://wiki.ubuntu.com/Security/FilesystemCapabilties
Comment by kees — July 6, 2010 @ 9:13 am