From: "Joseph Gooch" <mrwizard@psu.edu>
Date: Sat, 10 Jun 2000 02:58:07 -0400
Ok guys, this isn't going to work. The 2.2.16 patch pretty much took the
inheritable set and threw it out the window. At least before, you could
mask an entire capset and not have to worry about suid programs getting
elevated caps (if the program was capabilities 'smart'). Now we're back to
the uid 0 is root no matter what situation. Instead of fixing exec(), you
broke capabilites. Grr! I've been trying to track this down, here's what I
see.
Yes, that was deliberate. The problem is that allowing an attacker to
arbitrarily deny privileges to setuid root programs is dangerous.
CAP_SETUID isn't the only case where this could cause problems.
Consider what might happen if some program was denied CAP_CHOWN (and
didn't check for return values so it didn't notice that it failed), for
example. You could argue that the program was broken, but it was a
program that would have been secure everywhere but Linux.
Part of the problem was that people had a fundamental misunderstanding
about what the inheritable set was supposed to be used for. That
misunderstanding (and misuse) of the inheritable set caused the security
bug.
You can still bound what suid programs can use via
/proc/sys/kernel/cap-bound, on a global basis. It requires privileged
access, just as creating a chroot jail requires privileged access.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:24 EST