[lkml]   [2006]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
    Stephen Smalley wrote:
    > On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
    >> AppArmor (then called "SubDomain") showed how this worked in practice
    >> years before the Targeted Policy came along. The Targeted Policy
    >> implements an approximation to the AppArmor security model, but does it
    >> with domains and types instead of path names, imposing a substantial
    >> cost in ease-of-use on the user.
    > Just to clarify a few points:
    > - It is true that both AppArmor and SELinux with targeted policy only
    > (effectively) restrict a subset of processes, but SELinux with targeted
    > policy provides complete mediation of all objects and operations for
    > those processes, not just capabilities and files like AppArmor.
    Agreed, with the caveat that mediating all those things comes with
    expense, and AppArmor doesn't mediate them by design, because our goal
    is to keep the host from being compromised by a hacked application, not
    to control all information flow. Different goals produce different designs.

    > - Targeted policy demonstrates that a general purpose mechanism that is
    > capable of complete mediation of all processes, objects, and operations
    > (SELinux) can be applied to selective control if that is your goal. The
    > reverse is not true; AppArmor is limited by its design.
    Also agreed, and also caveated that the general purpose system emulating
    the simple system is much more complex than the simple system itself,
    and simplicity is a critical part of secure design. In this case, the
    most expensive impact on simplicity is the complexity of the policy that
    users have to manage.

    > - Ease of use should be addressed in the user interface, not by using a
    > broken kernel mechanism. There is ongoing work to address the
    > useability of SELinux in userspace; it doesn't require changing the
    > kernel mechanism to rely on pathnames (which is broken).
    Mediating by file names rather than inodes is the fundamental place
    where we disagree. I am delighted with LSM, because it allows us to
    disagree without having to fight about it.

    Crispin Cowan, Ph.D.
    Director of Software Engineering, Novell

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-18 22:39    [W:0.023 / U:0.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site