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