lkml.org 
[lkml]   [2005]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectSplitting up grsecurity and PAX (was Re: thoughts on kernel security issues
    From
    Date
    On Wed, 19 Jan 2005 16:03:06 EST, John Richard Moser said:

    (New Subject: line to split this thread out...)

    > > Even better would be a 30-40 patch train for PaX, a 10-15 patch train
    > > for the other randomization stuff in grsecurity (pid, port number, all
    > > the rest of those), a 50-60 patch train for the RBAC stuff, and so on.
    > >
    >
    > RBAC first. Some of the other stuff relies on the RBAC system, I'm
    > told. Not sure what.

    Well, there's 3 classes of stuff:

    1) Stuff that's basically independent of RBAC (a lot of randomization stuff,
    for instance). These can go as a separate stream.

    2) Stuff that is mostly independent of RBAC, but can use it for configuration
    and control. So for instance, the PAX stuff (which by itself is close to half
    the whole thing) could go in, and possibly with a "stub" patch that adds
    control via /proc/kernel/something or a /sys entry. And it's *OK* if your
    code has a "shim" in it to make patch 3 work until the new infrastructure
    that patch 27 adds shows up, meaning that patch 26 removes a big chunk of
    patch 3 (especially if your /sys shim stands on its own even without patch 27).

    3) The stuff that literally makes *no* sense if you don't have RBAC.

    It may very well make sense to attack the stuff in group (1) *first*, because
    then (a) all the kernel users get the benefits (similar to the "non-exec-stack"
    patch from execshield - everybody wins from that piece even though it's not all
    of the package), and (b) it's an easy way to pile up street creds by demonstrating
    with small patches that you are with the program - when some of the later, more
    contentious patches show up, it helps if you're recognized as the guy who
    already sent in 10-15 patches...

    > I think GrSecurity's RBAC is a bit bigger than LSM can accomodate.

    Well - what parts of RBAC *can* be done inside the LSM framework?

    What parts could be done inside LSM if LSM gained another hook or two (there
    *is* precedent for adding a hook for things that can reasonably use it)?

    What parts can't be done inside LSM, and why?

    > Anyway, I wasn't originally trying to get PaX into mainline in this
    > discussion; I think this started out with me trying to point out why
    > things like PaX have to be all-or-nothing.

    I agree that the sum set of features eventually included needs to cover
    all the bases - the big hurdle is factoring it down into patches that stand
    a chance.


    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:5.409 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site