Tomas Olsson wrote:
>What about possibilities to extend the interface by allowing the modules
>to store blobs on their own, connected to the main blob? I guess it would
>involve passing a blob ** in all hooks, or possibly just a locator function
>pointer upon registration. Doable?
>
>
I think someone else already discussed that and may have implemented it.
Nothing stops cooperating modules from using the security blob as the
head of a list of blobs. This has the advantage of not requiring any
changes to the LSM interface per se (and so can work now) and the
disadvantage of actually requiring the modules to cooperate on blob
management.
An LSM extension to manage the blobs would be a step farther down the
path of directly supporting stacking. The cost is considerable
complexity enhancement to do blob management; think about removing a
blob from a list of blobs in a race-free way on an SMP kernel. The
benefit is that multiple modules could be stacked that require use of blobs.
Which begs the question: does it *ever* make sense to use multiple
modules that use blobs? Off had, I say "no":
* All the blob-using modules I know of are some kind of MAC system
that is attaching state to a a process, and it never makes sense
to compose these systems.
* All the instances of multiple module composition that I do know of
amount to one MAC system and one or more pathology blockers like
TPE or OWLSM, plus the special case of POSIX Capabilities.
Anyone have a counter-example where they actually want to compose two
blob-using modules?
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
This archive was generated by hypermail 2b30 : Fri Jul 02 2004 - 12:52:48 PDT