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.
