Crispin Cowan wrote: > This is just a single instance of the general problem of security policy > composition. Oh, I agree that security policy composition can be non-trivial. But since there are cases where it IS reasonable, let's make sure we can handle the case. > One of the things an LSM can do is block module loading and > unloading, for very good reason. If someone has stacked on to you, they > may well have completely blocked any ability to load or unload. But in the end it's the stacker's decision on whether or not to allow the load/unload, since it's the STACKER that's called first, and can then call whatever else it wants to call in turn. > The general case is that security policies can conflict, making > effective stacking impossible. Fair enough. The point of the stacking stuff is so that, when they DO NOT conflict, you can do it. > I like the development of the stacker module. It makes stacking modules > much easier than stacking by hand.. But it does not surprise me that the > stacker module suffers the same limitations as stacking by hand, i.e. > many intuitively desirable operations (such as unloading a module in the > middle of a stack) are just infeasible. To be fair, that was merely a limitation of my implementation. There's nothing inherently hard about unloading a module in the middle of stack, it would just be another pointer manipulation. > Furthermore, I submit that because the stacker module is trying to > automate some core work that stacking by hand does by, er :) hand (such > as composition of security policy using a default-AND logic) that using > the stacker module will be even *more* restrictive than stacking by hand. If you don't care at all about performance, you could create an 'OR' and 'NOT' stacker, and if you allowed arbitrary nesting, you could do any binary operation. More realistically, given the source code to a default-AND logic, general-purpose stacker, it should be easy to devise stackers for specific cases, using the default-AND stacker as a starting point. --- David A. Wheeler
This archive was generated by hypermail 2.1.3 : Wed Jan 05 2005 - 10:03:21 PST