Messages in this thread |  | | | Date | Sun, 3 Nov 2002 01:37:19 -0500 (EST) | | From | Alexander Viro <> | | Subject | Re: Filesystem Capabilities in 2.6? |
| |
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/
|  |