lkml.org 
[lkml]   [2003]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BK PATCH] LSM changes for 2.5.59

    Christoph Hellwig wrote:
    > Well, selinux is still far from a mergeable shape and even needed additional
    > patches to the LSM tree last time I checked. This think of submitting hooks
    > for code that obviously isn't even intende to be merged in mainline is what
    > I really dislike, and it's the root for many problems with LSM.

    It is true that SELinux is not yet in mergeable shape, but we do intend
    to address those issues. With regard to additional patches, SELinux
    has at times diverged slightly from the main LSM patch, but we do feed
    back changes. At present, the only significant change in the
    additional patch has to do with early initialization of SELinux so that
    we can properly set up the security state of kernel objects when they
    are created rather than needing to retroactively set up the state of
    objects created before module initialization. That issue has come up
    in general for security modules on the LSM list, and we would need to
    submit a general solution for it along with the submission of SELinux
    for mainline. Hence, you are correct that there is work to be done
    before SELinux can be merged, but you are wrong to assume that we do
    not intend to do that work or to submit SELinux.

    > There has been a history in Linux to only implement what actually needed
    > now instead of "clever" overdesigns that intend to look into the future,
    > LSM is a gross voilation of that principle. Just look at the modules in
    > the LSM source tree: the only full featured security policy in addition
    > to the traditional Linux model is LSM, all the other stuff is just some
    > additionl checks here and there.

    I assume that you mean "SELinux" above. It is true that SELinux is the
    dominant user of the LSM hooks at present. We would have been happy to
    submit SELinux as a direct kernel patch rather than adding a further
    level of indirection via LSM, but that wasn't the guidance we were
    given.

    > I'm very serious about submitting a patch to Linus to remove all hooks not
    > used by any intree module once 2.6.0-test.

    Any idea on how much time that gives us (to rework SELinux and submit
    it)? Some of the necessary changes are simply engineering issues, but
    others require further dialogue, e.g. getting the API into an
    acceptable form, revisiting the approaches used to label and control
    access to pseudo filesystems.

    > Life would be a lot simpler if you got the core flask engine in a mergeable
    > shapre earlier and we could have merged the hooks for actually using it
    > incrementally during 2.5, discussing the pros and contras for each hook
    > given an actual example - but the current way of adding extremly generic
    > hooks (despite the naming they are in no ways tied to enforcing security
    > models at all) without showing and discussing the code behind them simply
    > makes that impossible.

    We would have preferred this route as well, but again it wasn't the
    guidance that we were given. We were told to work on something
    LSM-like, then told to wait to initially submit it until after certain
    other changes went into 2.5.

    > So yes, my suggestion is to backout the whole LSM mess for 2.6, merge
    > a sample policy core (i.e. a cleaned up flask/selinux) in 2.7.<early> and
    > then add one hook after another and discussing the architecture openly
    > where it belongs (here on lkml!).

    Leaving 2.6 with no infrastructure for access control extensions at all?
    Is this really preferable to keeping LSM in 2.5/2.6, and then migrating
    to a more directly integrated architecture in 2.7?

    --
    Stephen Smalley, NSA
    sds@epoch.ncsc.mil

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:0.027 / U:0.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site