Re: Making forward progress

From: jmjonesat_private
Date: Mon Aug 06 2001 - 10:34:24 PDT

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

    On Mon, 6 Aug 2001, Stephen Smalley wrote:
    > On Mon, 6 Aug 2001 jmjonesat_private wrote:
    > > 1) the more patches/work that get done within the "restrictive_only"
    > > model, the more work have to do here to convert from "restrictive_only" to 
    > > authoritative.
    > Moving DAC to a module is not the same thing as authoritative hooks.
    > I think that Crispin sent a note to Ted asking about moving DAC
    > to a module, not about authoritative hooks vs. restrictive hooks.  
    I know.  Although, I don't see how moving DAC checks (and what Linus said
    about capabilities and superuser checks) could possibly leave anything in
    the Kernel but function.
    > With regard to authoritative hooks, it isn't really true that
    > there is any conflict between the ongoing work and what is needed
    > for authoritative hooks.  In fact, moving the existing hook calls
    > after the DAC logic (which I did for permission in my recent
    > patch and I have just done for setattr, ptrace, setnice, setpgid,
    > and setscheduler) makes it easier to convert to authoritative hooks.
    > The other tasks I suggested in my original message in this thread 
    > don't really help with regard to authoritative hooks, but they
    > don't make it any harder to change to them, and they certainly
    > improve the overall quality of LSM. 
    I agree, somewhat.  Moving the hooks to after-in-kernel moves toward
    authoritative.  It also makes one FLAVOR of authoritative fairly easy: the
    one that let's in-kernel checks run and then just provides the "opinion"
    to the module.  A few in-kernel changes to jump to our hook, we are pretty
    much "in". 
    My concern is that there are many people working within the
    "restrictive_only", priority in-kernel assumption right now.  That
    assumption will have subtle consequences that may later cause us concern,
    or encumber other "flavors" of authoritative hooks. 
    I don't want to waste effort, I *do* think authoritative hooks have the
    advantages of being
    1) no less verifiable than restrictive_only, (I'm still willing to build a 
    stackable module that returns us to restrictive_only, as we've defined
    2) more generally useful for modules which MAY wish to override in-kernel
       logic, and
    3) more forward looking, to options and experiments which may later 
       enhance ACTUAL linux security, rather than just support the
    pre-existing experiments.
    I don't seek to "block" work.  What I seek to do is to impose upon the
    minds of those coding that their hooks/fixes MAY end up being viewed in
    the light of authoritative, and possible DAC-OUT authoritative.
    > --
    > Stephen D. Smalley, NAI Labs
    > ssmalleyat_private
    J. Melvin Jones
    ||  J. MELVIN JONES            jmjonesat_private 
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon Aug 06 2001 - 10:35:51 PDT