RE: Making forward progress

sdsat_private

On Fri, 3 Aug 2001, KRAMER,STEVEN (HP-USA,ex1) wrote:

> I'm amazed that the proposal for the authoritive hooks wasn't more widely
> endorsed.  It would allow all projects to go forward.  Instead, we read
> about a number of scenarios, that, while bringing up valid concerns, were
> performance concerns rather than roadblocks to implementation.  As has been
> pointed out many times, not everyone will be able to get all of what 
> they want.  But IMHO, that's better than excluding an entire project.

Back on June 12th, I posted a new LSM patch that changed many of the
hooks to be authoritative as well as providing a number of other
changes.  After some discussion on the mailing list and
resistance to the authoritative hooks, I posted a summary of
the pros/cons on June 14th (reposted for your viewing pleasure
below).  I subsequently changed the authoritative hooks to
be purely restrictive, and that version of the patch was accepted.
As someone who has actually tried changing the hooks to be
authoritative, I would have to say that it is more complicated
than you might think.  Anyway, here is the text from my
earlier posting:

<snip>

There is the view that we would be better off with simply
restrictive hooks (other than capable) rather than authoritative
hooks.  

Arguments in favor of this view seem to be as follows:
a) The permissive behavior supported by the authoritative hooks 
duplicates the permissive behavior of the capable hook and
only offers finer granularity, 

b) There is less need for finer granularity permissive behavior 
than for finer granularity restrictive behavior, and 

c) It is easier to verify restrictive-only behavior with
purely restrictive hooks.  

d) We cannot always provide authoritative hooks, since the existing logic
cannot always be colocated with the hook or cannot be easily decoupled
from the functional logic.

Arguments against this view are as follows:  
a) Fine-grained permissive behavior would be a useful feature to 
support in the future, e.g. allowing a process to override DAC
on certain sets of files rather than on all files, 

b) The duplication is no different than in the restrictive case, 

c) Verifying that a module is purely restrictive is a module
issue, not something that should be hardcoded into the kernel.

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