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

sdsat_private

On Wed, 6 Jun 2001 jmjonesat_private wrote:

> My objection is that, in any case, your solution requires the kernel
> logic to be evaluated before the module is called, and requires a 
> hook by hook decision as to if it may be relevant enough to include 
> the argument in the list.  

Having the kernel logic evaluated and passed to the module is quite
useful, both in allowing the module to be authoritative and in
allowing the module to audit the result of the overall decision.
It is unavoidable that we make a hook-by-hook determination,
because not every hook has corresponding kernel logic and even
when there is corresponding kernel logic, not every hook can be 
colocated with that logic.  But the question is not relevance,
just existence and colocation.

>This creates the following situation:
> 
> 1) Module designs that totally ignore the original kernel logic must
>    still wait for it to be resolved, discarding the result.

Totally ignoring the base logic would break applications.  
You can't arbitrarily change the kernel security model without 
impacting applications.

> 2) A consensus must be reached in the design of the interface to 
>    add "kern_retval" to each hook that "may" need it.  While we're 
>    all one big happy family ;), I suspect that different security 
>    module designs will need it in different places.  Requiring a 
>    central decision on where to add it instead of a mechanism that 
>    allows individual modules to "choose" if kern_retval is significant, 
>    (and, therefore, if it needs be calculated,) not only puts us in a 
>    perpetual argument for "add this", but forces those that don't 
>    need it to pay (the computational cost) for it.

It isn't a question of whether the hook may need the kernel
decision, just whether such a decision exists and can be
colocated.  Also, think about real security modules.  Most
of the access control modules under discussion are primarily concerned
with being restrictive, so they always want the kernel decision.
Likewise, auditing modules will want the kernel decision.

> 3) If you move the kern_retval check to AFTER the module, by the 
>    request of the module, it is possible that some of what is 
>    checked (such as euid) *may* be altered by the module before
>    the evaluation is done, allowing the module some influence 
>    in the result.  Yes, you could duplicate the check in the module
>    with a value changed, but now you're doing the check twice.

Consider auditing modules.  They need to know the final authoritative
decision, including both the kernel logic and the module logic.  
Under your scheme, they have to duplicate the check.  That seems
like a much more common situation than what you describe.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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