Selinux and Compiz: A SELinux rant

[Jerry Amundson]

On Mon, Oct 27, 2008 at 6:55 PM, John Morris <jmorris at beau.org> wrote:
> On Sun, 2008-10-26 at 16:29, David Nalley wrote:
>> I wish I could remember who to attribute this to, but someone on
>> -devel suggested that the same arguments occurred when firewalls were
>> really starting to become commonplace - a lack of knowledge of how to
>> manipulate and handle them caused repeated calls for their removal.
>> Mandatory Access Control isn't going away, and is really one of the
>> shining examples of Fedora leading the way with something and making
>> it far easier to use than it was.
>
> Wish I could be as optimistic but I'm not.  SELinux has been trying to
> get to a truly useful state since FC2 and still causes more problems
> than it solves for too many end users.  Are we expected to believe that
> it is about to finally 'just work?'

After years of will power to hold myself back from it, I caved in and
gave an enforcing SElinux system a chance ... and everyone knows where
that got me. [if you don't:
https://bugzilla.redhat.com/show_bug.cgi?id=468645]

> Yes it is great for a locked down server, and it's something any sane
> admin should try to use where a server is exposed to the wild Internet.
> On a very basic desktop that doesn't change much or run many different
> applications it doesn't do much harm... but also doesn't do much good
> either.  On a more power user desktop it will almost always blow enough
> stuff up to end up getting disabled in frustration.

It did harm on my "basic" desktop. And the response so far has been
"your user database is screwed up." Not "hmm, that's odd, how can we
fix it?", not even a "strange, how did that happen?". Yep, like I
purposefully sabotaged my SElinux environment...
Let me emphasize here that I see it's potential as a sysadmin.
However, the current mindset is to force it upon the user, and that,
simply, is narrow-minded.

> Compare and contrast to your example of enabling the firewall by
> default.  That caused problems because it was done before good graphical
> tools to control the thing were ready so end users had problems.  But
> any admin worthy of the name could deal with iptables wuth a manpage, vi
> (or emacs) and perhaps some Googling.  The number of people who can
> write SELinux policy is still in the hundreds (at most) after five plus
> years of Red Hat pushing the technology as hard as it can.

This is one of the points I was intending to make in my posts of the
past few days. Inside, I *felt* the state of selinux is dysfunctional
and wrong, but the *technical* part of me wanted to believe what I was
told. As usual, my technical experience confirmed what my instincts
told me - SElinux is not production quality. [And for those of you
considering it, don't bother playing the "rawhide" card.]

> And this new idea of using log scraping tools to automatically generate
> policy is simply an admission of that lack of skilled humans.  Anybody
> who thinks automatically generated policy is going to produce a secure
> system is delusional.  If enough humans who deeply understand SELinux
> existed to be able to double check these auto generated policies they
> could probably have written the darned things themselves.

You've really hit the nail on the head there. I've said it before, and
I'll say it again as long as necessary, software quality currently
sucks. Where did todays developers learn that it's OK to pass burdens
off to the end user? Oh, that's right, it's the open source way -
"someone else will test, fix, document, etc."
"patches greatly accepted" is another way of saying, "I don't care,
you do the work."

> Finally, the biggest objection is that it acts like alien technology
> bolted onto UNIX's security model as a totally different and parallel
> system.  And like alien tech humans can't understand it, they are
> expected to treat it as a big black box and to just trust that it works
> and doesn't hose them at unexpected times.  I can teach somebody the
> UNIX permission model in less than an hour.  Learning the admin arcana
> of sticky bits, SUID, noexec mounts and such takes a few more hours.  I
> read the O'Reilly book on SELinux and still don't think I understand it
> enough to write a sound policy.  It is hard to trust things that one
> can't understand, especially a security system that I'm supposed to
> somehow administer.

Amen.
Thanks for this. It drew me back from the darkness. That means
SELINUX=disabled and a relabel/reboot from now on, as I see from
installing Snap 3 today that "enforcing" is shoved down our throats.
But, I'm OK with that. I'm still inclined to "test it out" on *some*
systems - that's why I'm here. But I won't be fooled again.
Thank you also for "Whitebox" - It's still on a couple of my key
production systems (for now). It was my first exposure to what "open
source" and "community" really meant when combined together.

jerry

-- 
There's plenty of youth in America - it's time we find the "fountain of smart".