RE: Making forward progress

From: jmjonesat_private
Date: Fri Aug 03 2001 - 13:54:22 PDT

  • Next message: Stephen Smalley: "Re: Problems with some of the current hooks"

    On Fri, 3 Aug 2001, David Wheeler wrote:
    > It appears to me that there's increasing unrest with the restrictive
    > hook approach, with a number of problems being noted about it.
    > However, many seem to believe that removing _all_ existing DAC checks
    > from the kernel isn't allowable.  
    For anybody listening, some think it's not allowable, some think it would
    be allowable, but might be so much effort that it will break the camel's
    back at this point... so I'm looking for a strategy that allows it later
    without backtracking significantly, if the Cassandra's are correct (hrm,
    Cassandra... Casey... coincidence (j/k, late friday, my brain does that)).
    >And although various arguments have
    > been made, in my mind the major _advantage_ of restrictive hooks is their
    > ease of verifiability.
    > Let's examine a form we've looked at before:
    >   retval = (current-DAC-check);
    >   if (hook(retval, ...)) ...
    > This has several advantages:
    > 1. The DAC check is still in the kernel code.  That way, the "default"
    >    is clearly stated, and there's not problem with duplicate code that tries
    >    to emulate what the kernel "usually does".
    > 2. In many cases, this won't require many changes from what's done now,
    >    so I don't think it'd be too hard to switch from what's here now.
    > 3. Verification of security modules is the main advantage of restrictive
    >    hooks, though as noted, it turns out to be fairly easy to unintentionally
    >    mess things up anyway.  However, if all hooks start like this in a module:
    >     if (retval) return retval;
    >    Then you have a "restrictive-only" module.  This is trivial to verify
    >    by hand; at most, you need to check ~140 entries for a sophisticated
    >    security module.
    >    This could even be checked automatically.  Yes, this is something that
    >    needs checking, but hopefully no one is going to insert
    >    unchecked security modules into critical systems :-).
    I agree on all four points, and add
    4. Authoritative that allows in-kernel ("DAC", when convenient) to be
    reported to the module and potentially overridden begins to acknowledge
    that in-kernel MAY be something that should be moved out to a module.  By
    having it this way, it enables statistics to be gathered and considered
    with regard to how many modules actually ignore it, how many respect it
    restrictively, and how many might find other uses for having the kernel
    opinion, and how they do in the market.  This is the "forward/alternative
    path" acknowledgement I've been trying to argue that we need for weeks,
    but gotten nowhere with. 
    Furthermore, SGI or DACOUT(fictitious group) could work on the
    LSM-to-this-ideal patch and PRESERVE LSM as a viable group/authority,
    letting others deal with the "not easily placed" case and come to LSM with
    any modifications to the interface that may be essential.  Simply pass "no
    opinion" to our authoritative hooks and rip out the in-kernel checks, it
    becomes an idea somebody else can argue without arguing AGAINST the
    validity of LSM. 
    Dr. Wagner's "do you have proof/statistics" question can be answered this
    way without completely blocking us now.
    > Perhaps there are places in the code where it makes little sense to
    > permit a DAC override.  In which case, don't pass a "ret", and the
    > hook is restrictive (instead of authoritative).  That means that you'll
    > need to know, for each hook, if it's restrictive or authoritative,
    > which can be determined from its prototype.
    > This _does_ mean that, performance-wise, DAC checks always execute first.
    > However, the kernel developers will want the COMMON case ("no fancy
    > security module") to be fast, and paying for a few more cycles isn't
    > likely to be a problem on systems worrying about advanced security
    > mechanisms.  Indeed, on most processors, the function call
    > will almost certainly swamp any other performance payment you make.
    > For the case of "the DAC security values are on tape", perhaps such
    > DAC values should be implemented via a stackable security module instead
    > the filesystem.
    I'm not, personally, sure that the performance hit is a strong argument
    either way... that data is not yet "in".  The "flexability" is more dear
    to me... processors get faster and more efficient all the time, and
    concerns that want "high" security will have to decide if they want to pay
    for it individually.
    While ripping EVERYTHING out of the kernel now and allowing "return
    permission" authoritative modules might certainly help the embedded
    community, I don't yet have statistics that say it doesn't impose far
    greater cost on the community at large.  Authoritative after in-kernel
    *wherever possible* moves us all toward getting that data and possibly
    working out a solution *later*.
    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 : Fri Aug 03 2001 - 13:57:04 PDT