Selinux and Compiz: A SELinux rant

Daniel J Walsh dwalsh at redhat.com
Tue Oct 28 12:56:25 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jerry Amundson wrote:
> 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
> 
SELinux has a bug in the selinux-policy-targeted package that fails to
setup the user database correct if the package is initially installed on
a disabled system.  If you later turn SELinux on, your database is
screwed up so you were not able to login.   The post install executes
these commands
semanage -S targeted -i - << __eof
user -a -P user -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u
user -a -P user -R guest_r guest_u
user -a -P user -R xguest_r xguest_u
__eof
semanage -S targeted -i - << __eof
login -m  -s unconfined_u -r s0-s0:c0.c1023 __default__
login -m  -s unconfined_u -r s0-s0:c0.c1023 root
__eof

Which basically setup the default user and root account to login as
unconfined_t.  Since SELinux was disabled these commands failed.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkHC/kACgkQrlYvE4MpobOlkACg6kYIxOjYv5D3ffgL52xmhMaI
LwMAoKW/cAEYmQs6Lc3Jj6a0VIk2pWqa
=TheD
-----END PGP SIGNATURE-----




More information about the fedora-test-list mailing list