lkml.org 
[lkml]   [2006]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/11] security: AppArmor - Overview


    --- James Morris <jmorris@namei.org> wrote:


    > You are conflating the policies provided with
    > SELinux systems with the
    > mechanisms of SELinux.

    You have defeated me. My unabridged Webster does
    not define "conflating" or even conflat, and I
    guess that I'm too unhip to be up on it's modern
    usage. Before I disagree with you, I'd like to
    know what I've been charged with!

    > One of the important features of SELinux is its
    > policy flexibility, with
    > clean separation of policy and mechanism.

    Except that every single time I'm meet with
    SELinux developers they have emphasised how
    important it is to use the Official Policies.

    > SELinux provides the mechanisms
    > to control all security relevant access of processes
    > to data, and accesses between processes.

    Truth.

    > It is up to the policy to determine how much of that
    > mechanism is
    > utilized, according to desired security goals.

    Yes. And a complete system policy is enormous.
    500,000 rules and growing, last I heard.

    > Targeted policy in fact does perform a
    > usability-security tradeoff (as all
    > real security systems must do),

    In Orange Book terms this was known as policy
    not applying to all objects.

    > aimed at the relatively simple case of
    > protecting systems with a few internet facing
    > services. This is the
    > default policy shipped with _millions_ of Fedora and
    > RHEL systems, and
    > represent, to the best of my knowledge, the first
    > ever releases of general
    > purpose operating systems with MAC enabled by
    > default.

    Except that MAC is NOT enabled by default, it is
    available by default. Only those programs and objects
    identified by the policy are constrained.

    > The aims and limitations of targeted policy are very
    > well documented.

    I'm old, so I won't say they're "very well"
    documented,
    but they are documented. The limitations of the
    targeted
    policy rarely show up in the glossy, however.

    > If you wished, you could load a simpler policy which
    > can offer an
    > equivalent level of protection offered by non-MAC
    > schemes such as
    > AppArmor. In fact, some work has been going on more
    > generally in this
    > area in Japan during the last couple of years.

    Yup. The policy description would still be large.

    > Other types of users will want stricter policies, to
    > meet their security
    > goals. The SELinux mechanism is general enough to
    > cater to very high
    > levels of protection and assurance.

    Yes it is. It works, I admit. There are even
    applications
    I'd suggest it be used for.

    > So, please, consider that the mechanism of SELinux
    > is quite separate from
    > the types of policies which may be deployed.

    Can't do that. The mechanism require large, complex
    policies.

    > And that arguments regarding SELinux "complexity"
    > often confuse these
    > issues, as well as issues around tools and
    > abstractions presented to
    > users.

    The underlying mechanisms are more complex than
    Bell & LePadula MAC + Biba Integrity + POSIX Caps.

    I am not trying to knock SELinux (too hard) in
    this discussion. I do want to point out that many
    of the arguements being used against alternatives
    apply to SELinux as well. I do not understand why
    SELinux developers feel so threatened by alternatives.


    Casey Schaufler
    casey@schaufler-ca.com
    -
    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: 2006-04-25 18:03    [W:9.054 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site