David Wagner wrote:
>By the way, people say that "general stacking is too difficult, so let's
>not think about stacking at all". I still have doubts that this may end
>up costing us in the long run. It seems that there are some special cases
>that are of considerable interest and that nonetheless seem quite feasible
>to handle: for instance, we have two restrictive-only modules M and M',
>and we want to compose them, allowing only actions that both M and M'
>would allow; this is safe and easy to do well, I believe, if we design LSM
>in the beginning to support composition.
>
Hmmm ... if LSM is purely restrictive, and purely access control, then
general composition may become feasible:
* chain all the hooks: if any module says "no", then the answer is "no"
* chain the blobs: each blob is actually a list of blobs, and each
module walks the list of blobs looking for its own
This is not what we have designed, but it is conceivable, and
potentially quite valuable.
On the other hand, going down this path really locks out authoritative
hooks and anything but restrictive access control policy engines, now
and forevermore.
Is it feasible to allow some subset of LSM modules to engage in this
protocol, and thus permit generic stacking of "restrictive-only access
control modules"? I don't know. There would have to be a way for a
module to declare itself to be a member of the ROACM Cabal :-) so that
the stacking mechanism will let them in. It's kind of problematic, and
depends on the code details.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Sep 06 2001 - 17:36:32 PDT