lkml.org 
[lkml]   [2006]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    --
    Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
    Director of Software Engineering, Novell http://novell.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-18 22:39    [W:0.033 / U:33.764 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site