Messages in this thread | | | Date | Fri, 16 Apr 1999 11:44:35 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Hi Andrej, Thanks for the excellent info; you've stimulated some possibly good thoughts for me...
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/
| |