Re: in defense of SELinux

On 10/16/2013 11:18 AM, David Nicol wrote:
>
> On Thu, Oct 10, 2013 at 2:09 AM, Jed Donnelley 
> <capability-iCFHVraI1K1Wk0Htik3J/[email protected] <mailto: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.

I guess that depends on what you mean by "locking down" and "production".

In my admittedly limited experience SELinux policies are 1. Complex, and 
2.  Brittle.

#1 makes it unusual for sysadmins to modify SELinux policies for any 
services, production or not.

#2 makes it likely that any changes to how a service is configured will 
run afoul of an SELinux policies despite being an entirely reasonable - 
not sacrificing security except in the sense of conflicting with SELinux 
policies.

If:

A.  by "locking down" you mean improving security by making it more 
likely to trap a hacking attempt, and

B.  by "production systems" you are referring to systems used 
essentially unchanged in their service mechanisms from how the SELinux 
policy was developed,

then I agree with you.  This limited applicability of the SELinux 
approach to improving security and the limited value that it provides 
even in it's sweet spot applications to me has always seemed that it's 
costs were too high for what it provides.

Still, if you think of it independent of it's implementation costs and 
happen to want to deliver a service that it's tuned for, then I agree 
that it can add some protection.

My gage reflex is the result of spending untold hours trying to keep 
some SELinux policies working through some needed service configuration 
changes, which I considered minor, and ultimately being forced (to 
conserve always limited sysadmin time) to give up and turn off SELinux.  
Not a positive experience.  That was many years ago.  It looks like I 
may be asked to try again soon. Hopefully the experience this time will 
be more positive and we'll at least be able to run with SELinux enabled 
on some servers (likely web servers) to get some of the limited 
additional protection that it offers.

--Jed

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