Well, you're right as it currently stands. The problem is those UID
'compatibility mode' options were meant to hold us over until the
filesystems could support capabilities, which spawned an entire OTHER
argument on how that should be done. (ext2+caps,elfcap,et al) As far as I
can see, interest in capabilities is limited to myself, and Mark Heuse
(compartment for SuSE). I haven't seen much else development in programs to
use capabilities in the past year. Personally, I have working
'capabilities-smart' bind-8.1.2 chroot, ping and traceroute, apache, and
pidentd. I've used compartment to jail mysql with no caps. It's a great
feeling to know that even if someone exploits bind, since i've given it
cap_net_bind_service+ep, they will end up with a zeroed capset, and even if
they find a suid program, they still won't have any caps. Capabilities DO
WORK, it's just no one has looked at them in soooo long. I've been wanting
to see filesystem support since they came out but no one seems to be doing
anything anymore, and it's a damn shame.
All I can do at this point is make sure what's there now isn't broken to
save some other functionality problem.
Joseph Gooch
> -----Original Message-----
> From: Albert D. Cahalan [mailto:acahalan@cs.uml.edu]
> Sent: Sunday, June 11, 2000 12:40 AM
> To: linux-kernel@vger.rutgers.edu
> Cc: mrwizard@psu.edu
> Subject: Re: Process Capabilities on 2.2.16, Sendmail problem
> revisited
>
>
>
> 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:23 EST