On Fri, 16 Apr 1999, Andrej Presern wrote:
> On Thu, 15 Apr 1999, David L. Parsley (lkml account) wrote:
[snip]
> >I'm interested in why you think it's fundamentally broken. In the design
> >issues I'm considering, it seems at _worst_ to be much better than the
> >current root=all powerful model.
[snip]
> As for POSIX privileges, a specific design based on capability lists, it
> contains a number of design failures besides the obvious disadvantages of
> capability lists. For example, the POSIX privileges concept makes a distinction
> between the permitted and the effective set of capabilities. In security
> reality however, there is no 'permitted' set, only the set of effective
> capabilities. When a capability is a single system call away (that can be taken
> by the process anytime and from any point), marginal security gained by
> 'turning off' a capability in the 'effective' set but leaving it 'on' in the
> 'permitted' set is exactly zero, making the set of permitted capabilities
> effectively the set of effective capabilities. In other words, your process is
> either able to do something, or not able to do something - an extra syscall or
> two makes no difference.
Ok, I agree completely with this; I don't see any good use for fE, it
really doesn't enhance security; if someone can explain to me why it
might, I'd be interested (Ted?)
>
> Furthermore, the POSIX privileges contain the third set of capabilities, the
> inheritable set, which is also a design failure as it makes the design to fail
> to contain the damage in case of a buggy privileged binary. Once a privileged
> binary is broken into (for example at runtime by means of a stack overrun), it
> can be made to spawn an arbitrary child (such as a shell for example) that will
> inherit the authority of a buggy parent, thus enabling an attacker to gain
> unauthorized access in a useful form (a shell for example). Because you never
> know how the inherited authority will be used, inheriting authority in a
> computer system is just as bad as when a stupid prince inherits the throne of
> a great king.
Ok, this is what gave me pause; I've been considering how to design a
system around our capabilities model, and pI' = pI can be a problem in
many cases. I suggest we drop the fE concept, and use it instead as an
inheritable mask, fM, and change the formula for inheritable to: pI' = pI
& fM. This is nice for 'dead-end' programs, such as telnetd or httpd,
which really shouldn't allow spawned process' to inherit from it.
Instead, these should merely have CAP_NET_BIND_SERVICE for fP, for
instance. Using this extension, you allow programs to inherit privs when,
say, run by an administrator; but they inheritance will 'dead-end' with
that program. This is good for, say, Ted's example of a trusted program
calling 'more'.
Thoughts?
[snip]
> As I said above, I would not like to speculate whether POSIX privileges would
> bring an improvement in security or not as that depends very much on the
> implementation details. From a designer's point of view, they are inadequate
> and broken and will in combination with existing subsystems lead to further
> extensions and ad hoc solutions to solve the security problem.
Well, if we all agree that fE is pretty much useless, I think fM would
give a useful added flexibility to use in designing a secure distribution.
cheers,
David
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/