SElinux

[Robert Nichols]

Craig White wrote:
> On Mon, 2006-04-03 at 03:27 -0500, Robert Nichols wrote:
> 
>>Craig White wrote:
>>
>>>if Windows exploits are any indication, it is primarily desktop systems
>>>which are the target for malware that infects the system for nefarious
>>>purposes. Why? Because the users are often not knowledgeable, run with
>>>elevated privileges, travel to web sites that attempt every conceivable
>>>exploit in a plethora of scripting languages, etc.
>>>
>>>The policy updates from Fedora have been frequent and are automatically
>>>installed/applied
>>
>>True, and they might even be workable on a system that is set up
>>with 100% standard file system structure and users whose interaction
>>with the OS is limited to clicking on icons.  Add a separate
>>filesystem for large downloaded files or have a user that uses the
>>(gasp!) command line to do bizarre things like redirect the output
>>from ping onto a file in his home directory and SELinux starts
>>blocking you at every turn unless you can spend the time to become
>>an SELinux guru and figure out what needs to be tweaked in the
>>policy or attributes to fix things _this_ time, and try to guess
>>how badly that change will break when tomorrow's policy update gets
>>installed.
> 
> ----
> I am no SELinux guru - I would reserve that distinction for someone like
> Paul Howarth.
> 
> I have noticed though that even with my limited skill sets, SELinux has
> been very manageable and the alterations to targeted/policy/sources has
> been easily managed on FC-3, FC-4 and RHEL-4. I haven't played with FC-5
> but I know there are new tools.
> 
> Likewise, changing file contexts with chcon have been relatively simple.

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.

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.

-- 
Bob Nichols         Yes, "NOSPAM" is really part of my email address.