Re: The Demise of Simple Assurance?

From: jmjonesat_private
Date: Wed Aug 01 2001 - 12:40:58 PDT

  • Next message: Crispin Cowan: "Re: The Demise of Simple Assurance?"

    On Tue, 31 Jul 2001, Crispin Cowan wrote:
    > jmjonesat_private wrote:
    > > Authoritative hooks are generally useful and modules that need the "simple
    > > assurance" argument can use a stacked module that guarantees it.
    > That's an interesting idea.  However, in trying not to change too many variables at
    > once, I think it's important that this idea not mandate any additional substantive
    > changes to the LSM interface itself.  JMJ, do you believe that your "simple assurance
    > preserving module" can be made stackable without additional LSM changes?
    We've given it a look, and the results are more mixed than my intuitive
    evaluation suggested to me...
    1) It appears that passed pointers to structures can be protected by a
       stacked module, even without going authoritative at this time.  The
       cost is partially the same as the benefit: structures and substructures
       (etcetera) could NOT be altered unless the guardian module specifically
       allowed it.
    2) The module could provide somewhat MORE assurance value if it had the
       results of the  in-kernel checks as an argument, protecting the return
       value in a "bottleneck" where it could be more easily shown that a 
       permission could never be returned if access was denied by the
       in-kernel checks.
    3) The cost of this sort of protection, on a scale of 1-10 is somewhere 
       around 20.  Structures need to be copied and return conditions
       evaluated.  Sometimes, it can get pretty "hairy".  Justification for 
       putting it in a module that ONLY those who REALLY need it would employ.
       How valuable simple assurance is and if the cost is worth the benefit
       would have to be evaluated on a product by product basis.
    > > I'll put resources into writing it, since having an open source module allows more
    > > assurance.  This is NOT impossible, but it is not possible (imho) within the
    > > hooks/interface without tripping the "more invasive" trap that has ALSO been sprung
    > > many times.
    > Could you elaborate? Does going authoritative do the job?  What else do
    > you need? 
    Although it breaks my heart (toasts my butt?) to admit it, going
    authoritative is NOT absolutely necessary to build a guardian module...
    however, let me introduce one final plea:
    Many decisions have been made with regard to the design of the interface
    using "simple assurance" as a trump card.  While the argument "can't
    return a permission if in-kernel checks would deny" is valid, to a certain
    extent, with restrictive_only hooks... it now appears to me to be
    trivially easy to alter kernel structures in ways that turn those
    in-kernel checks into module puppets, forcing them to return almost any 
    result one wishes.  In essence, restrictive_only placement of hooks only
    HIDES the fact that they are possibly-authoritative.
    Admittedly, a compromised module is a disasterous thing.  End-Of-Game. 
    Heck, if a virus can carry a payload that rewrites vmlinuz (or even dumps
    a kernel image somewhere and modifies /etc/lilo.conf as root, then reboots
    (scarey, huh?))... the game is over, too.  A subtle bug in a module is
    probably going to be relatively common, and the current working interface
    allows bugs to mash and twist kernel structures in ways that make "simple
    assurance" a very shakey platform to stand on. 
    I remember discussions not long ago that actually seemed fairly "split"
    with regard to authoritative hooks, and have seen pleas and arguments that
    they will be more useful in the future for a variety of interests...
    arguments I believed because they fell in line with my own work.  The
    argument of "simple assurance" tipped the balance, justifiably... but *I*
    don't see it as being strong enough to support restrictive_only thinking
    in this new light... since a stacked module (or module-by-module coding)
    is now necessary to shore up the assurance either way, and can readily 
    force the results to be "restrictive".
    The idea that "something is better than nothing" ... lock the doors and
    leave the windows open?  That's not much assurance.
    I don't have all the answers.  I don't think this whole group together has
    all the answers... good theories and ideas fall prey to the 11ty-4 jillion
    crackers out there every day.  I *am* willing to put resources behind a
    "guardian" module and open it up for review and community revision and
    ridicule.  Since it will concentrate the issue into a shared space between
    the interface and the module, we can "put our simple-assurance eggs in one
    basket and watch the basket", and return the interface to authoritative,
    which is honestly what it *potentially* IS now, and then focus on dealing
    with the problems and ramifications resulting therefrom... while
    developers won't be constrained by an argument that was *right*, but
    didn't actually work out in practice. 
    I can not argue for pulling the DAC (in-kernel checks) out to the module,
    this is too invasive at this point... but having an authoritative
    interface might give substance and the benefit of "long standing proof" to
    the idea out around Linux 3.0 or 4.0, I don't know... but the mechanism
    might be the same: stack the DAC, prove it, then you have DAC and a
    GUARDIAN in front of a module ... or modules that want to SUBORDINATE DAC
    and call it only if, say, MAC fails, can do so ... "in the distant
    > > Crispin
    > --
    > Crispin Cowan, Ph.D.
    > Chief Scientist, WireX Communications, Inc.
    > Security Hardened Linux Distribution:
    > Available for purchase:
    My 0.2 cents (^_^),
    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 : Wed Aug 01 2001 - 12:43:10 PDT