Re: Thinking about stacking in LSM: merge registering, add info about field use to security_operations

Previous message: Lachlan McIlroy: "Re: Thinking about stacking in LSM: merge registering, add info about field use to security_operations"
In reply to: Matt Piotrowski: "Re: Thinking about stacking in LSM: merge registering, add info about field use to security_operations"
Next in thread: David Wheeler: "Re: Thinking about stacking in LSM: merge registering, add info about field use to security_operations"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

chrisat_private

* Matt Piotrowski (matt.piotrowskiat_private) wrote:
> On Thursday 18 July 2002 06:39 pm, Chris Wright wrote:
> 
> > * David Wheeler (dwheelerat_private) wrote:
> 
> > > It's not clear to me that a multiplexor could really
> > > "account for it properly", since it doesn't have the
> > > information it needs to detect this problem.  Actually,
> >
> > It's simple.  Keep a stack of security ptrs.  Swap out for the module
> > specific ptr before you ask the module's opinion and iterate through
> > the module stack.
> 
> Hmmm, seems like there would be complications.  Consider a security module 
> which, for whatever reason, does something like this:
> 
> current->security->inheritable_trait = 
> current->p_pptr->security->inheritable_trait;

point well-taken.  this is a nice illustration of why we've discouraged
generalized stacking and only given enough stacking support to allow
for modules that already know how to play together.  SELinux keeps a
magic number in its blobs so that it at least can identify the blob.
another solution is building more stacking smarts into the framework,
something we've really intentionally steered away from.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module