lkml.org 
[lkml]   [2007]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
    On Sun, 30 Sep 2007, Andrew Morton wrote:

    > So with the information which I presently have available to me, I'm
    > thinking that this should go into 2.6.24.

    I think the decision to merge Smack is something that needs to be
    considered in the wider context of overall security architecture.

    Smack itself looks fine. It seems like clean code with interesting ideas,
    and appears to be based upon sound principles.

    Merging Smack, however, would lock the kernel into the LSM API.
    Presently, as SELinux is the only in-tree user, LSM can still be removed.

    LSM's weak semantics and pervasive deep hooking of the kernel means that
    we'll have to continue dealing with several unpleasant issues, such as the
    abuse of the API by out of tree vendors, with a proliferation of
    binary/proprietary modules which typically maladapt the API for arbitrary
    purposes and/or use dangerous techniques. We will continue to waste
    resources maintaining this capability for them.

    On a broader scale, we'll miss the potential of Linux having a coherent,
    semantically strong security architecture. I have written about this in
    some detail before: http://lwn.net/Articles/240019/

    Briefly, SELinux is a security architecture. It provides an extremely
    high degree of flexibility, in terms of both the types of security models
    implemented, and security policy for those models. It allows controlled
    composition of different security models, with a common policy language
    framework, allowing the entire system to be analyzed. The same ideas and
    even code can be reused beyond the kernel as post-DAC security is extended
    into databases, the desktop, distributed applications etc. It is a
    framework which provides a structured, coherent view of the security of
    the OS (and ultimately, the entire distributed environment).

    If LSM remains, security will never be a first class citizen of the
    kernel. Application developers will see multiple security schemes, and
    either burn themselves trying to support them, or more likely, ignore
    them.

    Core kernel developers will continue to not have enough information to
    understand what the LSM hooks in their code are supposed to be doing,
    leading to long term maintenance issues and potential security problems.

    LSM will remain a magnet for bad ideas. There's a reason we don't have
    pluggable network stacks, and we are lucky to have had a unified
    networking framework maintained by people who know to say no to things
    like STREAMS and TOE. I would question whether this quality of
    maintainership would exist if the networking core was simply a bunch of
    deep hooks into which people dumped arbitrary custom stacks.

    LSM will prevent us from making systemic improvements to security, as
    there will be no common security architecture. Things like Netfilter
    would not have been viable with a kernel which simply provided a bunch of
    hooks for networking stacks and an assortment of implementations.

    Much of this we have learned from the experience of LSM, and I think it
    has been valuable for that, but I think we need to consider now whether we
    are going to continue down this track in a permanent manner.


    - James
    --
    James Morris
    <jmorris@namei.org>
    -
    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: 2007-10-01 13:35    [W:0.057 / U:184.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site