Khimenko Victor wrote:
> Huh.I can be wrong but why, oh WHY everyone is trying to add low limits in
> design just to try to break then later ? 32, 64 or 128 WILL NOT be enough in
> long run.
Massive numbers of capabilities will make development and
deployment of trusted applications difficult. The 44 capabilities
(there are some holes, it's really less than that) in Irix are
sufficient to send developers screaming for the good-ole-days
when checking for uid==0 (or calling suser()) was all they had to
do. The value of capabilities is not in their granularity, but in
the seperation of the uid from the ability to violate policy.
After two beers I can argue that a single capability is better than
the old uid based scheme.
I am not making this warning from a theoretical point of view. I
have been working on and with capabilities (the system I'm sending
this from has no superuser) for years. While you can argue that a
fine granularity of capabilities makes for a safer system, it
also leads to abuse of the mechanism. With a capability hammer
available, many problems start to look like nails.
Application policy enforcement is not well suited to capabilities.
Capabilities are a kernel enforcement mecahanism, and adding things
like a capability required to edit /etc/passwd just clutters it up.
For that, I'd suggest a program list mechanism.
--Casey Schaufler Manager, Trust Technology, SGI casey@sgi.com voice: (650) 933-1634
- 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 : Tue Feb 15 2000 - 21:00:27 EST