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
