[saywatnow]

Your loss. I agree that the way it's sold as "EASY" (caps appropriate) is a bit ridiculous, but SELinux does add a stong layer of protection from vulnerabilities in one service leading to total server pwnage. Ignore the rhetoric and try to work with it - the peace of mind pays off.

[sgt]

What if an app does something during runtime that you had not catered for? This effectively means potential downtime for the app while your admins are trying to figure out why the app is failing.

I agree SELinux adds something to the table, but the article shows two examples (httpd_sys_content_t and httpd_can_network_connect). Let's assume there is a third httpd_can_foo_bar that is required down the line. And then a http_can_bar_quux a few hours after that. All in all this can be a bit risky. Perhaps if there was an easier way to administer SELinux?

[corney91]

1. Functionality that'll be used should be tested before going into production.

2. Using something like setroubleshoot will make sure any SELinux denials appear in the syslog so should be simple to diagnose, and sealert will tell you likely solutions. Personally I think that's how distros should be shipping SELinux, not sure what the downsides are.

Note, I'm mainly talking about servers here. Personal computers always seem to have messily-packaged applications running, so I can see why people get annoyed with SELinux there (although I've never had a problem with Fedora, yet...)

[jlgaddis]

It really isn't that difficult once you understand the terminology and methods. It is absolutely worth the effort to learn, in my opinion.