Re: Authoritative Hooks

From: Valdis.Kletnieksat_private
Date: Mon Nov 05 2001 - 14:21:34 PST

  • Next message: Greg KH: "Re: Authoritative Hooks"

    On Mon, 05 Nov 2001 14:16:33 PST, Greg KH said:
    > On Mon, Nov 05, 2001 at 12:58:43PM -0800, Casey Schaufler wrote:
    > > I understand the "foot in the door" approach. Watch your toes,
    > > and be ready to spend a long time waiting for something
    > > useful to get in. I'm disappointed, and now have to figure
    > > out how to address the real issues this position raises.
    > That's a pretty unfair statement.  Your use of "useful" is relative.
    > The current LSM patch is very useful to a number of existing security
    > projects: SELinux, DTE, vserver, OpenWall, SubDomain, NetDomain, and
    > others.
    On the other hand, it's interesting that the current patch is "useful"
    to a number of projects that all operate in the context of the limited
    model provided (restrictive-only hooks), but which has been conclusively
    shown to NOT be useful for anything that wants authoritative hooks.
    I have to agree with Casey - this puts SGI in a *very* bad spot, because
    they *want* to ship audit and ACL support, but doing so would force them
    to explain why LSM wasn't sufficient.
    And let's face it. If we step back a bit and look at it, this *does*
    look silly:
    "Well, we could use Linux - the new LSM stuff provides security exits"
    "Would we be able to do ACLs?" "Erm, no. They decided against supporting that."
    "Would we be able to generate an audit trail?" "Erm, no. That got dropped out."
    "Then what's it good for?" "Erm... SOME stuff uses it"
    "Why isn't the rest of the stuff in there?" "They thought a real solution
    wouldn't be accepted"
    "So what you're saying is that the Linux world isn't serious about security?"
    Now let's go back and look at Crispin's 3 concerns:
       1. It is more invasive.
    Yes.  But not by much - and *EITHER* authoritative or restrictive hooks
    are invasive.  Personally, considering the fact that this is an attempt
    to bolt security onto a project after the fact (usually a bad idea), it's
    surprising that it's as non-invasive as it is.
    /dev/random is pretty invasive too - it's got its grubby hooks into the
    disk drivers to gather entropy and all that.  Should it have been made
    a lot less invasive by only gathering entropy from one or two places?
    Or should it be invasive enough to get the job done?
    The base LSM patch (lsm-2001_10_24-2.4.13.patch.gz) is 9,356 lines long.
    Richard Offer's update of authoritative hooks subtracts *33* lines, and
    adds *68* lines.  Once you allow for a *lot* of add/sub pairs being movement
    of a line of code, that's less than one percent bigger than the base LSM
    It's surprising how 10,000 lines of patches are acceptably invasive, but
    another 40 lines of code is too much.
       2. It increases the likelihood that modules can accidentally
          undermine the base logic.
    Compare that to the likelyhood that a solution that is half-LSM and half patch
    will screw the base logic.
       3. It increases the likelihood that the LSM patch will introduce an
          error into the base kernel.
    Kernel errors will happen.  See the 2.4.11 kernel for an example.  There's
    been LOTS of code that got added to the kernel that wasn't quite ready
    the first time around - that's what the 2.3 and 2.5 series are *for*.
    And how *DID* Arcangeli's VM get dropped into 2.4.10?  That's a *HELL* of
    a lot more invasive than anything we're writing.  Added in the middle of
    a 2.4 series, to boot.  We're collectively a damn sight lucky that *THAT*
    not-at-all-invasive change didn't introduce any errors into the kernel,
    aren't we?
    But *NO*.  We need to worry about upsetting people with large patches in
    the 2.5 stream, even if they're only 25% bigger and make it a lot more
    usable for a lot more projects.
    				Valdis Kletnieks
    				Operating Systems Analyst
    				Virginia Tech

    _______________________________________________ linux-security-module mailing list linux-security-moduleat_private

    This archive was generated by hypermail 2b30 : Mon Nov 05 2001 - 14:22:39 PST