RE: Making forward progress

From: David Wheeler (dwheelerat_private)
Date: Fri Aug 03 2001 - 11:59:11 PDT

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

    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.  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 :-).
    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.
    However, from the point-of-view that some standards etc. say "check A then B",
    then from the user's point-of-view that's what happened
    (even if B is computed first, the result of A is authoritative...
    I'm ignoring the CPU covert channel).
    IIRC, on x86's, up to 4 arguments are usually passed via registers using gcc,
    so >4 arguments passed are somewhat slower.  Not sure if that'll make
    much difference here.
    Stephen Smalley said:
    >Alternative DAC mechanisms can be implemented using LSM - you simply
    >implement your new DAC logic in the module and if you want your logic to
    >completely replace the old DAC logic, your module uses the capable hook
    >to override the old DAC logic.
    This is true, though if people really want to do this, restrictive hooks
    are a terrible way to do it.
    Anyway, my two cents.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Aug 03 2001 - 12:01:06 PDT