Re: permissive vs. restrictive issue and solutions...

chrisat_private

* David Wagner (dawat_private) wrote:
> 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.
> 
> In this context, a proposal I made earlier might be relevant.
> I hope noone will mind if I repeat myself a little bit.
> 
> Introduce a translation layer.  The base kernel logic will still contain
> calls to security_ops->hook(), and this will resolve to the translation
> layer.  LSM's can register permissive_hook(), a restrictive_hook(),
> or both with the translation layer.  The translation layer can then be
> in charge of registering a security_ops->hook() with the base kernel to
> ensure that the relevant LSM *_hook()s get called.

The placement of the hook is critical.  When you say "the base kernel
logic will still contain calls to security_ops->hook()" I'm not clear on
the placement of the hook.  And, that is the crux of the issue.  If the
hook placement is before or after the standard DAC checks, you can't
override the DAC checks.  If it is embedded with the DAC checks in a
compound conditional then you are choosing either permissive or
restrictive depending and logic.  Maybe I'm missing something.

> 
> If this general approach is to be followed, there should still be
> some discussion on the details.  For instance, what are the semantics
> when a restrictive_hook() says 'deny' and a permissive_hook() says
> 'allow'?  Possibly it is better to have a restrictive_hook() and an
> override_hook(), where the latter always takes precedence and allows
> fully general policies, intended to be used only where restrictive_hook()
> is insufficient.

This sounds complicated to me.  It also seems dangerously close to
enforcing policy in the lsm (since as you mentioned we'd need to decide
how to integrate the results of a restrictive and permissive hook).
Adding possibly triple the hooks feels like an unnecessary burden on the
module.

I think I prefer moving the logic to the module, or passing the results
of the base kernel logic to the module (both seem to be a simpler to
keep policy in the module).

-chris

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