Joseph Gooch writes:
> 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.
I knew this would happen. Below is a message I sent just a
few days before the news broke. Hopefully now people will
believe me when I say this feature is just broken as designed.
(this was written in response to the argument over draft 16
and draft 17 behavior, the two of which are incompatible)
Well, anyway: I TOLD YOU SO !!!!!!!
---------------- original message to linux-kernel -------------
List: linux-kernel
Subject: RE: Bug in how capability inheritance is handled in
From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Date: 2000-05-31 3:57:31
I have to ask, why is this in the kernel at all?
I wish this hadn't gotten past Linus. It seems to be poorly
thought out. Even now, years (?) later, there is disagreement
over the basic algorithms. Who even uses this stuff?
IMHO this feature is even a security risk. Normally, a program
that needs capability bits gets them all. If a non-root user
runs the program, it will fail at the first privileged call.
Now, with the bits separate, failure can occur mid-way through
the program. This can leave the system in a half-way state.
This IRIX-like system suffers from a granularity problem.
What reasonable way is there to split capabilities? The DG-UX
system doesn't have to answer this question because there is
a nice 1:1 mapping between capability bits and the real world.
(Done right, you need lots of bits. Done wrong... why bother?)
Remember what this whole system is supposed to do. UID values
were to _not_ grant power. This works great if, like DG-UX,
the OS reserves some bits for use outside the kernel. If you
don't do this, you have TWO INCOMPATIBLE SECURITY SYSTEMS
operating at the same time. The kernel-only distinction is a
serious error, obviously made because of the strong desire to
avoid dealing with the user-defined bit allocation issue.
Now, explain all this to a typical business admin, considering:
1. the complex and non-intuitive formulas
2. the lack of a 1:1 mapping to the real world
3. basic incompatibility with the UID system
4. UID still grants power, via user-space access control
Never mind the users! Just explain this to a common admin!
At best we have an unused feature. At worst we have a security
disaster waiting to happen. How about starting over? Really, it
would be nice to see this ill-defined system ripped out.
-
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:22 EST