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

dawat_private

Chris Wright wrote:
>> 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.

Yes.  That's true.

Maybe one way to avoid this conundrum is to pass a flag indicating
the results of the DAC checks to security_ops->hook().  e.g.,
  if (current->uid != current->euid || ...) // DAC
    rv = EPERM;
  rv = security_ops->foo_hook(rv, ...);
  if (rv)
    return rv;
  do_foo();
I've been travelling a few days, and have paged out some of this stuff.
Was there a reason to prefer to avoid passing such a flag to hooks?
If I've forgotten one, I apologize profusely for my forgetfulness.

>> 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).

Policy in the lsm -- isn't that where lsm is supposed to go?
Note: I would advocate making the translation layer as optional and part
of the policy module system.

>Adding possibly triple the hooks feels like an unnecessary burden on the
>module.

Yes.  Good point.  It might make sense to allow the module to register
any one of permissive_hook(), restrictive_hook(), or authoratitive_hook(),
but no more than one.

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