oss-sec mailing list archives
Re: filesystem capabilities
From: Sebastian Krahmer <krahmer () suse de>
Date: Mon, 8 Nov 2010 12:37:35 +0100
Hi, To me it looks like an error condition where you should die() if you see +s root AND fscaps applied. From my tests, you cant get rid of the suid of 0, whether you drop setuid(getuid()) after cap_set or before. It seems like in that case the kernel handles you like a suid binary with +s to nobody. You cant get rid of the nobody-suid if called setuid(getuid()). Even though all HOWTOs/READMEs tell you that root is nothing special if using caps and dropping all caps so it "is like nobody" this aint true. Having most of the important files like /etc owned by uid 0 is like implicit having CAP_DAC_OVERRIDE and thats basically full root with full caps. And to make things complete we not only have to deal with libcap (which I personally prefer even if its "more complex to use"), we also have cap-ng (http://people.redhat.com/sgrubb/libcap-ng) where a first look at the provided ping etc patches shows me that again the return values are not checked for capng_apply(). (My fault if it does and I overlooked it) And the whole cap/priv framework must *always and always* check return values as shown a dozens of times that this gives cool root exploits. And I dont want to mention the semantics change between the kernel versions (2.6.25 etc). Sebastian On Mon, Nov 08, 2010 at 11:28:13AM +0100, Ludwig Nussel wrote:
Solar Designer wrote: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.There are requests for openSUSE too.- 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.Exactly. A community submission of an fscaps enabled iputils package brought the issue to our attention. We were astonished that the prime example ping doesn't drop it's capabilities. So it actually shows why blindly applying fscaps doesn't help security at all. So we are going to treat fscaps just like setuid bits and require code review by the security team.You also absolutely have to deal with passwd, which would be another SUID root program. Like we did: http://www.openwall.com/tcb/ And with all others (e.g., our crontab/at and crond changes). :-)The next step would be to get rid of those setgid programs too then. A daemon controlled via unix domain sockets could do the job just as well I suppose.Thanks for reading this far, and I'd appreciate any comments and/or corrections. Some of the info above might be outdated - e.g., I am not sure of what current kernels require (or not) to drop capabilities.AFAICT there are no special capabilities needed.(If they no longer require anything extra to drop CAP_SETUID, then that's a security problem on its own - the "sendmail risk" is back.)Thanks for the reminder! I actually didn't know. Here's a link explaining sendmail's problem: http://archives.neohapsis.com/archives/sendmail/2000-q2/0002.html Indeed I ran into the trap when trying to patch ping to drop capabilities. If a program is capability aware but still installed setuid it needs to setuid(getuid()) before dropping it's capabilities. Doing it the wrong way around keeps the POSIX saved uid and setuid(0) is still possible even though getuid() == geteuid() and no capabilities granted. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer () suse de - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
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 Kees Cook (Nov 10)
- Re: filesystem capabilities Ludwig Nussel (Nov 08)