[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101108113735.GA18713@suse.de>
Date: Mon, 8 Nov 2010 12:37:35 +0100
From: Sebastian Krahmer <krahmer@...e.de>
To: oss-security@...ts.openwall.com
Subject: Re: filesystem capabilities
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@...e.de - SuSE Security Team
~ 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.
