SElinux

[Matthew Saltzman]

On Tue, 4 Apr 2006, Robert Nichols wrote:

> Changing file contexts is very simple.  Knowing what to change a
> file context _to_ in order to fix any particular denial is not so
> simple.  And fixing the root problem that is repeatedly causing
> similar denials requires quite a bit of knowledge and analysis.

I've seen references to audit2allow that make me think this tool should 
help identify what needs to be changed to fix any particular denial. 
Haven't investigated in detail yet.

>
> The standard policies pretty much work on a totally standard
> installation.  Add a couple of disk drives or partitions for
> particular purposes (huge downloads that don't need to be backed
> up, the news spool, online copies of the most recent backups),
> move a couple of standard directories to simplify administration
> and space allocation (/home is actually part of /var, /opt is
> located in /usr), and SELinux becomes a huge can of worms.  Yes,
> I've written additions to the context rules so that autorelabel
> will work, only to see my work invalidated when a policy update
> introduces new types.  BTDT, but a this point I've burned the
> tee shirt.
>
>>> I'm sure SELinux can be great on a server where a well defined set
>>> of operations are performed over and over, but trying to write a
>>> security policy that can accommodate the huge variety of things
>>> that can be legitimately expected to be done on a desktop system
>>> looks like a task doomed to failure.
>> 
>> ----
>> I don't see that - I see people conceding defeat without trying. Again,
>> I think the biggest obstacle is the use of language tokens that make it
>> appear to be complicated where if it were natural language, far fewer
>> people would be freaked out.
>> 
>> In reality, it's not a server/desktop thing. It's only a matter of
>> whether said user is willing to spend the time/energy necessary to
>> understand at the very least, how to stop SELinux blocks from happening.
>> It looks like rocket science, it's not rocket science.
>
> It is very much a server/desktop thing.  On a server you aren't
> constantly doing unique things that are inconsistent with the way
> that server has been running.  And any time you _do_ make a change
> to what that server is doing, you know your first task is to
> check that it's all working properly or fix whatever you just
> broke.  On a desktop, that sort of new and different activity
> happens all the time, and being in the middle of a task and
> suddenly having a program fail and now you need to put on your
> SELinux Guru hat is intolerable.  Before I can even consider
> enabling SELinux on any of my systems, here are two non-negotiable
> demands:
>
> 1. I need to be able to enable just small pieces of a policy.
>    Targeted policy seemed like a good idea in FC-3.  Problem
>    is that the policy's appetite for new targets has exceeded
>    its ability to digest them, and the amount of effort needed
>    to understand how it is all supposed to work has been
>    increasing exponentially.
>
> 2. I need to be able to override AVC denials in real time --
>    allow this access, or fix the underlying cause, then let the
>    program continue.
>
> Until I see both of those, I'll continue to add "selinux=0" as
> a kernel parameter during installation.
>
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs