Re: in defense of SELinux

Hi Rob, what do you mean by "mandatory access control"?


On Wed, Oct 16, 2013 at 2:08 PM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

> 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
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>



-- 
    Cheers,
    --MarkM

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk