[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Nov 2010 11:28:13 +0100
From: Ludwig Nussel <ludwig.nussel@...e.de>
To: oss-security@...ts.openwall.com
Cc: Daniel Walsh <dwalsh@...hat.com>
Subject: Re: filesystem capabilities
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)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
