Re: Common header for security blobs

dawat_private

Stephen Smalley  wrote:
>This is true, but the lack of a common header makes a lot more work for
>the multiplexor module.

On this point, I'm not sure I agree.  I wonder whether the real problem
here is that we're missing interfaces and abstractions designed for
composition.  It's well-known in software engineering that if you don't
design for composition up front, it's often much harder after the fact.

For example, I'd argue that modules should never insert themselves
by writing directly into the security_ops struct, but should call
some register_lsm() interface and pass in the desired struct setting.
Similarly, modules should never touch current->security directly, but
instead we should pass in a security field as the first argument to
each hook (much like the 'this' parameter in an object-oriented system),
or it should be available via a getsecurityblob() and setsecurityblob()
interface, or something like this.  Introducing this sort of abstraction
gives us the freedom to later introduce some forms of composition.

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.  Therefore, I'd argue that the
right answer may not be "give up on all forms of stacking", but rather
"give up on general stacking, but consider the possibility that we may
at some point in the future want to support certain special common cases".

I know people are uninterested in stacking, so I won't push on this, but
I just wanted to point this out as a potential gotcha in the long run.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module