Re: Authoritative Hooks

From: Greg KH (gregat_private)
Date: Mon Nov 05 2001 - 16:04:01 PST

  • Next message: Crispin Cowan: "Re: Authoritative Hooks"

    On Mon, Nov 05, 2001 at 05:21:34PM -0500, Valdis.Kletnieksat_private wrote:
    > "So what you're saying is that the Linux world isn't serious about security?"
    Audit, and ACLs do not make up all of "security" :)
    No, what the LSM group decided was to not support audit or ACLs right
    now (and I haven't seen an ACL patch yet, to really verify this.)  What
    they did decided to do is support the most minimal security patch they
    could at first cut, which happens to support quite a number of different
    security models.
    > It's surprising how 10,000 lines of patches are acceptably invasive, but
    > another 40 lines of code is too much.
    The fact that 4 lines of patch causes a syscall to totally change it's
    logic model is quite invasive.  The number of lines don't really matter.
    In fact, the majority of lines of code in the patch is documentation,
    followed by empty hooks, as the attached diffstat of the 2.4.13 lsm
    patch shows.
    >    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.
    Huh?  If you want to have your own patch, you can do whatever you want
    and mess up the base logic.  That's up to you.  I don't understand your
    argument here.
    >    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?
    The VM changes are not our concern.  They were done by people with a
    _huge_ history of good solid kernel modifications.  The LSM team (as a
    whole) has _no_ history of good kernel modifications.  The way to earn
    that kind of trust is to contribute small, good, clean, and easily
    provable as such, patches.  Only over time can you earn that kind of
    trust.  We need to earn that trust.  Submitting huge patches that
    radically change the base logic of the kernel does not help in achieving
    that goal.
    > 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.
    "A lot" so far == 2.  And no one has really proven the second one (ACLs).
    How many projects work with the current patch?  A bunch.  How many will
    work if we don't get any LSM patch in?  None :)
    greg k-h

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

    This archive was generated by hypermail 2b30 : Mon Nov 05 2001 - 15:06:17 PST