-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerry Amundson wrote: > On Mon, Oct 27, 2008 at 6:55 PM, John Morris <jmorris@xxxxxxxx> 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----- -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
