Re: in defense of SELinux

On Wed, October 16, 2013 20:18, David Nicol wrote:
> On Thu, Oct 10, 2013 at 2:09 AM, Jed Donnelley
> <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>wrote:
>>
>> ---  Just a mild style comment on the talk:  Dr. Watson seems very
>> deferential in his discussion of comparisons with MAC mechanisms - such
>> as SELinux.  I have to admit that I have an automatic gag reflex
>> whenever I write or speak the word SELinux, but I think that even
>> objectively Dr. Watson didn't make clear just how problematic the global
>> policy mechanisms of something like SELinux are.  It's like trying to be
>> God or a Communist government developing a 10 year plan and tracking,
>> via explicit policy, everything that goes on in a computer system (not
>> to mention network).  Things change too quickly.  It simply can't be
>> done.   With capabilities (access control objects) you allow the
>> programmers to manipulate access control where it makes sense through
>> the communication channels between what he refers to as "sandboxes" (in
>> other contexts processes or domains).  I believe this distinction is
>> significantly more than religion.
>>
>
> SELinux is appropriate for locking down production systems, and for that
> purpose it works as designed.
>

>From my OHM2013 "defeating trojans" speaker notes:

"Within a single domain of administration and at
relatively course granularity levels, its often a good
idea to create and enforce policies that hinder the
freedom to delegate. That is, creating 'mandatory'
access controls.
While these policies can lead to tighter security, they
don't scale up that well to inter organizational
interaction, neither do they scale down very well to
the finer granularity levels of individual objects.
Mandatory access control policies are notoriously
hard to create and maintain once you start to
approach the granularity levels of processes. On the
other side of the granularity spectrum, cross-domain
mandatory control remains a challenge.

When we look at access control on Linux we see the
old UNIX discretionary access controls for the
file-system. When we look at sub-user authorization
granularity on Linux, we get into the area of Linux
security modules that implement mandatory access
controls. These two models can seriously get into
each-others way. The best known Linux security model
without any doubt is SELinux. SELinux is amazing for
military organizations and government agencies
working with classified documents and security
clearances. If your main concern however are Trojans
and software vulnerabilities, you will want to use an
alternative that doesn't require system administrators to
have master degree in information security. AppArmor,
used by Suse and Ubuntu Linux, is such a security
module. AppArmor's mandatory model and the
sparse-cap based model also happen to be quite
complementary."

Needless to say I feel AppArmor for most non MLS purposes is by far
superiour to the more complex and granularity restricted model provided by
SELinux. While still doing MAC, unlike SELinux, AppArmor has a simple
model thats quite compatible with capabilities and other forms of
authority based access controll on other levels of granularity.

There is definitely value in restricting delegation in certain settings at
certain granularity levels, so at the risk as being stoned here for
heresy, yes mandatory access control has its place. However, capabilities
incompatible mandatory access control like offered by SELinux comes with
the price of not scaling up (to inter organisational levels) and not
scaling down (to object levels) as it provides a  model incompatible with
the inevitably discretionary requirements at those courser and finer
granularity levels.

Rob