Re: Filesystem Capabilities in 2.6?

From: Alexander Viro (viro@math.psu.edu)
Date: Sun Nov 03 2002 - 01:37:19 EST


On Sat, 2 Nov 2002, Linus Torvalds wrote:

> Why? Because then the suid check will work, and not only will you get all
> capabilities (_if_ the suid was root), you will also have changed your ID
> (since that was how you got enough capabilities to be able to mask them
> off).

Umm... As for getting all capabilities, I was planning to do the following:
modify suid check to give you everything except the mask taken from vfsmount.
So that's no problem - this is exactly the place I would modify.
 
> Which you do _not_ want to do. You just want the capabilities, you don't
> necessarily want to run as somebody else (or if you do, that "somebody
> else" might well be "nobody"). So suid vs capabilities are different: you
> may even want them to be complementary.

Now, _that_ may be more serious. However...

> In other words, it would actually make perfect sense to have
>
> -r-sr-sr-x 1 nobody mail 451280 Apr 8 2002 /usr/bin/sendmail
>
> mount --bind --capability=chown,bindlow /usr/bin/sendmail /usr/bin/sendmail

*blam*

Congratulations with potential crapload of security holes - now anyone
who'd compromised a process running as nobody can chmod the damn thing
and modify it.

And that is the reason why suid-nonroot is bad. It creates a class of
binaries that can easily give you a root compromise if one of them has
an exploit - even if that one is never run by root. That is the reason
why such things are done with sgid-nonroot and not with suid. Member of
group can't chmod. Owner can. And yes, you can take away chmod - but
you need to do that for everything that will run with that UID. Which
might be impossible - some might need chmod(2).

FWIW,
$ ls -l /usr/sbin/sendmail
-rwxr-sr-x 1 root smmsp 617672 Oct 2 13:33 /usr/sbin/sendmail

- no suid at all. And making it suid-nobody would decrease security.

Note that _all_ binaries that need any capabilities now are written to
be suid-root. So the only case left from your scenario is
        * new binary
        * runs with UID of caller
        * wants some capabilities
        * doesn't want to be portable (it won't work on any other Unix,
since we had assumed that it doesn't want to be suid-root and still
relies on caps present)
        * doesn't use any of $BIGNUM portable mechanisms (separate
helpers, descriptor-passing, yadda, yadda).

Umm... Do we really want to help these out? We don't even have an
excuse of that being an important 3rd-party program brought from some
other system - it will be Linux-only and new, at that.

Now, _removal_ of capabilities on exec makes a whole lot of sense -
suid or not. So IMO correct way to look at the stuff that adds them
as suid-root slighlty mitigated by removal of some things.

I can do addition of capabilities via the same mechanism - it's trivial.
But I really doubt that we want it as first-class thing.

Comments?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:28 EST