Re: Common header for security blobs

crispinat_private

David Wagner wrote:

>Crispin Cowan  wrote:
>
>>Hmmm ... if LSM is purely restrictive, and purely access control, then 
>>general composition may become feasible:
>>
>Yup, glad you agree.  That's what I was trying to argue.
>
Yes, I agree.

>(And I suspect this example of taking the intersection of two
>restrictive-only policies is one interesting example of a special case
>we can handle, but maybe not the only such.)
>
I'm basically a skeptical luddite :-) so you'd have to show me. 
 Security policy composition has a long and ugly history.

>>On the other hand, going down this path really locks out authoritative 
>>hooks and anything but restrictive access control policy engines, now 
>>and forevermore.
>>
>Hmm.  I must admit I don't see why.  What it does is ensures that you
>can only use this type of stacking with restrictively-only modules.
>
It just seems like its likely there will be problems supporting auto 
stacking and authoritative modules in the same kernel patch. I don't 
know what the specific problems will be, but I expect some kind of 
consistency problems and hair-pulling when one tries to implement it.

On the other hand, I could be wrong.  If I am wrong, then it would seem 
to me that it should be possible to implement a module stacking module 
that will only stack restrictive-only modules.  Stacker would have to 
trust modules when they declare themselves to be restrictive-only, but 
from there could do automatic multiplexing.

>Why problematic?  For instance: Add a flag to the register_lsm_module()
>interface, so that the module declares whether it is restrictive-only
>or not.  It's up to the module developer to know which class his module
>falls into.  You can lie to register_lsm_module(), but if you do, you
>deserve what you get.
>
This would seem to be the core question: what LSM enhancements would the 
ROACM Stacker need?

    * Any kind of changes to the hooks?  Or can Stacker just export the
      same LSM interface to the stacked modules?
    * Security blobs: can we get away with Stacker owning the security
      blobs that the LSM interface in the kernel provides, and then
      using each of these blobs to be the head of a linked list of blobs
      that stacked modules want to allocate? What I'm imagining here is
      that each of the stacked modules will think that it is the only
      module, and manage its blobs accordingly.  The kernel wil think
      that there's only one module (the Stacker).  In between, the
      Stacker module would have to manage the blobs, i.e. when the
      kernel calls free_blob on a blob, Stacker would walk its list of
      blobs and call free_blob for each of the corresponding modules it
      has stacked.
    * Anything else that stacking would need?

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