oss-sec mailing list archives
Re: filesystem capabilities
From: yersinia <yersinia.spiros () gmail com>
Date: Mon, 8 Nov 2010 12:52:29 +0100
On Mon, Nov 8, 2010 at 3:52 AM, Solar Designer <solar () openwall com> wrote:
Kees, all - There's a lot of talk lately regarding replacing the SUID bit on program binaries in Linux distros with filesystem capabilities. Specifically, Fedora and Ubuntu are heading in that direction. Fedora: http://fedoraproject.org/wiki/Features/RemoveSETUID https://bugzilla.redhat.com/show_bug.cgi?id=646440 Ubuntu: http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/ https://wiki.ubuntu.com/Security/FilesystemCapabilties While in general this is a good idea, there are issues with it, in arbitrary order: - Some currently-SUID programs are aware of them being (potentially) SUID, and will drop the "more privileged" euid when it is no longer needed, but they will probably not be aware of them possessing capabilities. This may result in larger parts of the programs (sometimes orders of magnitude larger) running with elevated privileges (or with allowed-to-be-elevated privileges, which is a privilege on its own and is usable through vulnerabilities that allow for arbitrary code execution). Let's consider ping, which appears to be the classical example of "where filesystem capabilities will help" (or so it is claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain somewhat-limited type), then drops root privs (if it was installed SUID root and run by non-root), then proceeds to parse the command-line, resolve the provided hostname, and so on. If the SUID bit is replaced with cap_net_raw+ep, as seen in Kees' example above, will ping know to drop this capability? Hardly. Not without a source code patch. Besides, dropping the capability might [need to] require privileges beyond CAP_NET_RAW itself (recall the capability-dropping attack on sendmail from a decade ago). So does moving from SUID root to cap_net_raw+ep improve security? Most likely not. On the contrary, it results in hundreds of lines of ping's code and thousands of lines of library code (DNS resolver) running with elevated privileges, as compared to just a few lines of ping.c, which was the case with simple SUID root. Granted, those "elevated privileges" are a lot less than root privileges, but they're a lot more than having a single raw socket of a specific type.
Are you perhaps questioning that the linux capability model, based on POSIX 1.e, is not fine grained ? Well, perhaps. But it the capability model is always in a DAC framework, and it is possible to augment with a MAC framework as selinux, for example. That it is what it was written about this (probably you know already http://www.linuxsymposium.org/archives/OLS/Reprints-2008/hallyn-reprint.pdf) " That being said, privilege is not the only use of the root identity. There are many files, such as are to be found in /proc/ and /etc/, that are owned by root. Even without super-user privilege, a process running in the context of an impotent root user, can still do a large amount of damage to a system by altering these files. Here, DAC and MAC based security will continue to be important in securing your Linux system. " But this not make the capability model without use IF the application are not capability aware. In fact I do not see why if I can not use a MAC mechanism, for various reasons, why I don't should at least be able to reduce the privileges of applications.Just for a simple example if rsyslog could be use a simple user + some capability should be probably sufficient for many as a residue risk : but today many distro REQUIRE the MAC framework active because rsyslog run as root: sure it is better to have a MAC framework ALSO in place if possible. In short every security mesure augment the overall security, the famous defense in depth. If i have a MAC system, for example, should be BAD to don't pose any other security mesure in place - as a host based firewall or a Web application Firewall, if i am using web application.
- In some cases, the capability sets being granted are (almost) equivalent (or expandable to) full root powers. This is seen in: http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch<http://people.fedoraproject.org/%7Edwalsh/policycoreutils_setuid.patch> -%attr(4755,root,root) %{_bindir}/newrole +%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole Well, not a good example newrole . newrole in selinux target policy is a
confined (newrole_t) selinux application : i don't can, for example, load a kernel module (CAP_SYS_MODULE) for example sesearch -A -s newrole_t -c capability Found 3 semantic av rules: allow newrole_t newrole_t : capability { dac_override fowner setgid setuid audit_write } ; allow newrole_t newrole_t : capability { chown fowner fsetid sys_admin } ; allow newrole_t newrole_t : capability net_bind_service ; OTHO, newrule IS capability aware and drops its capabilities, from a quickly code reading, almost. In short over the next few years I think there we will be close to the model described here http://www.friedhoff.org/posixfilecaps.html But certainly it will not be easy, require much work. Just for example in some distro "prelink" drop linux capability https://bugzilla.redhat.com/show_bug.cgi?id=456105 for now. Best Regards Elia
Current thread:
- filesystem capabilities Solar Designer (Nov 07)
- Re: filesystem capabilities Ludwig Nussel (Nov 08)
- Re: filesystem capabilities Sebastian Krahmer (Nov 08)
- Re: filesystem capabilities Kees Cook (Nov 10)
- Re: filesystem capabilities Sebastian Krahmer (Nov 08)
- Re: filesystem capabilities yersinia (Nov 08)
- Re: filesystem capabilities James Morris (Nov 08)
- <Possible follow-ups>
- Re: filesystem capabilities Steve Grubb (Nov 08)
- Re: filesystem capabilities Steve Grubb (Nov 08)
- Re: filesystem capabilities Kees Cook (Nov 10)
- Re: filesystem capabilities Steve Grubb (Nov 10)
- Re: filesystem capabilities Kees Cook (Nov 10)
- Re: filesystem capabilities Steve Grubb (Nov 10)
- Re: filesystem capabilities Kees Cook (Nov 18)
- Re: filesystem capabilities Daniel J Walsh (Nov 18)
- Re: filesystem capabilities Kees Cook (Nov 10)
- Re: filesystem capabilities Ludwig Nussel (Nov 08)