Assurance, permissiveness, and restriction

blockdevat_private

Crispin Cowan wrote:
> So here's yet another idea:  split the LSM interface into two 
> parts, permissive and restrictive.  Designers that want 
> purely restrictive functionality use only the restrictive 
> parts, and thus get easier/higher assurance. Those who want 
> permissive functionality can turn it on if they need it.
> 
> "Split" may be an over-statement.  Perhaps just a global 
> switch that can disable the permissive interfaces would 
> suffice?  Then a module designer could turn off 
> permissiveness, and be assured that their module will "at 
> least do no harm."

This switch should not be global, in the senses of being either
compile-time, or effecting all modules.  If there is any logic
to the "assurance" argument it remains valid if the module in
question simply doesn't access any of the permissiveness granting
hooks.

My understanding is that it is a project goal to dictate no
security policy but, rather, leave that to each of the modules.
Meddling with the ability of some module to make certain things
more permissive works against this goal.

I think the multiplexor module chaining can actually solve this
problem; if the standard security choices were implemented in 
a single module, and if a multiplexor were written that allowed
for overriding particular hooks, it would allow all of the
"default" code to live in one place, and for particular modules
to override this on demand.  For those applications that would
require an override this might introduce some additional overhead,
but, I think it would make it even easier to modify policy and
customize the amount of overhead introduced (for instance, an
embedded application could choose to not utilize the default,
multiplexing module but, instead, a super-permissive "return 1"
module).  I have a feeling that the "default" permission set
and this multiplexor should be in the same module.

Or was this the discussion of this idea one of the many things
which has already flown over my head in this thread? :)

  -- Matt

--
Brainbench Linux MVP
Transcript ID# 355889
http://www.blockdev.net/

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