RE: Making forward progress

From: Stephen Smalley (sdsat_private)
Date: Fri Aug 03 2001 - 09:04:00 PDT

  • Next message: jmjonesat_private: "Re: Making forward progress"

    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:
    There is the view that we would be better off with simply
    restrictive hooks (other than capable) rather than authoritative
    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
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Aug 03 2001 - 09:05:35 PDT