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.311 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site