On 04/01/12 10:45 PM, alikhan damirov wrote:

I don't know about statistics, but selinux have log's. Watch here: http://wiki.centos.org/HowTos/SELinux By default SELinux log messages are written to */var/log/audit/audit.log*

I believe the OP was asking about the statistics of how many CentOS systems have it on vs off. I don't believe anyone has taken any such survey, and there's certainly no appropriate data collection mechanisms in place to deduce this automatically. surveying a particular population would have built in biases based on the nature of the organizations surveyed and their policies.

On Mon, Apr 2, 2012 at 5:28 AM, Johnny Hughes johnny@centos.org wrote:

...

Just wondering if there is any statiscs report of selinxu usages in production environment? I know some still turn it off.

If you have machines purposely serving things to the masses on the Internet, you should take the time to make SELinux work properly on those machines.

Another statistic I'd like to see is how much admin time this costs on the average to learn and implement. Has anyone really measured this? Are there training courses specifically to cover it? You might get an idea from the length and cost of the training if it covers all the quirks. These days most of the built-in stuff is pre-configured for someone's idea of working (apache not being able to send mail doesn't match my definition, though...), but any third-party or local additions to a targeted service will take time to set up.

On Monday, April 02, 2012 08:51:46 AM Les Mikesell wrote:

Another statistic I'd like to see is how much admin time this costs on the average to learn and implement.

No more than proper firewalling techniques cost, really.

Has anyone really measured this?

Probably not.

Are there training courses specifically to cover it? You might get an idea from the length and cost of the training if it covers all the quirks. These days most of the built-in stuff is pre-configured for someone's idea of working (apache not being able to send mail doesn't match my definition, though...), but any third-party or local additions to a targeted service will take time to set up.

EL6 greatly improves the admin interface for SELinux with policycoreutils-gui as then all the booleans are quickly available (like the boolean that turns on or off httpd's ability to send e-mail (or connect to a network socket, etc)). The booleans (at least most of them) are in EL5, but the interface isn't nearly as well documented (I know, many would like a TUI with the click boxes; maybe one is out there, maybe not; I'm not allergic to a remote GUI being available on a server).

The documentation for EL6 is better in this regard as well. But, really, if you're having an issue with httpd getting 'access denied' things, then you can simply: # getsebool -a |grep http

The booleans have reasonable, and readable, names that make sense, for the most part. Find the boolean that controls the feature you want, and use setsebool to set it to on.

It's not hard, and the admin overhead once you're used to it is a few seconds at most. It becomes another 'firewall-like' item to check off, really, as long as you do things at leat in a semi-standard way.

And ls-lZ is your friend, along with chcon. It is one more step, but, honestly, it's not nearly as big a step as firewalling (ipchains/iptables) was ten/fifteen years ago. At least not with EL6; but EL5U8 is better than EL5 GA was.

To the OP's question: all but one of our CentOS boxen here have SELinux on, and in enforcing mode with either the targeted or the strict policies. The strict policy is tough to get right, and is for special use servers on the DMZ, typically, with the targeted policy running everywhere else. Including all the CentOS workstations we have, and even my Fedora laptop. The one CentOS box with it on, and in permissive mode, soon will be in enforcing once I have the small amount of time necessary to work out the AVC's and set up the proper contexts.

And SELinux has blocked a few attacks at this point for which there weren't yet patches; in other words, SELinux saved me from having to reimage servers that would have been pwned had SELinux not been running. I can't give more detail than that due to NDA, sorry.

Again, compared to all the options firewalls give you (connection tracking, DPI, UDP versus TCP ports versus IP protocol numbers versus non-IP protocols versus IP flags versus.....) SELinux is not hard to configure from the admin's point of view. Now, from the application developer point of view, things are different. But, there again, it really boils down to making sure the files you create have the proper context, and writing policy to fit your access pattern.

Increasing system security is not easy, and it takes time to do correctly, but it needs to be done in today's internet environment.

On Monday, April 02, 2012 10:34:58 AM Les Mikesell wrote:

So at least another grumpy, overworked full-time administrator for a typical company?

Perhaps. It depends upon how willing the existing admins are to learn something new, and on how overworked they are.

I'm as overworked as anyone; it wasn't that hard when I just decided to learn to live with it instead of expending increasing effort to buck it.

On Monday, April 02, 2012 11:27:54 AM John Doe wrote:

...self-compiled...

As Jamie Hyneman would say, "well, there's your problem."

Having said that, I run Plone on a few sites, and the only way to run Plone reliably on CentOS is to use the Plone-distributed unified installer, which compiles its own version of python, amongst other things. It took very little time to get that to run properly with CentOS 6.2 and the standard VirtualHostMonster proxy technique through apache httpd (couple of SELinux booleans and proper contexts on /opt/Plone/*). It took longer to set up the firewall rules than it did to set the SELinux boolean (since I needed WebDAV and remote client access to the ZEO server). That's with the targeted policy; with the strict policy it would be more difficult.

The standard first step when something isn't working right is to make sure the contexts are correct; a relabel with restorecon -R -r on that tree is the first step, and beyond that a complete filesystem relabel (easy-peasy way: touch /.autorelabel and reboot (something you can do when the next kernel update comes down the update pipe)). The Samsung Unified Drivers for their multifunction printer devices falls into the category of being challenging; but now I know that to get it to work I just have to relabel /usr. No biggie. (The Samsung drivers are a story unto themselves!).

And once you've done it for a particular app, document and/or script it so you can do it again more quickly (and give back to the community that makes all this possible by putting it on the CentOS wiki or somewhere).

The first time I tracked down some 'mysterious' SELinux bad mojo took a while (much like the first tiime I tracked down some firewall nonesense for H.323 NAT traversal across cisco!). The next time it didn't take as long.

On 02/04/12 15:10, Lamar Owen wrote:

On Monday, April 02, 2012 08:51:46 AM Les Mikesell wrote:

...

Another statistic I'd like to see is how much admin time this costs on the average to learn and implement.

No more than proper firewalling techniques cost, really.

...

Has anyone really measured this?

Probably not.

...

Are there training courses specifically to cover it? You might get an idea from the length and cost of the training if it covers all the quirks. These days most of the built-in stuff is pre-configured for someone's idea of working (apache not being able to send mail doesn't match my definition, though...), but any third-party or local additions to a targeted service will take time to set up.

EL6 greatly improves the admin interface for SELinux with policycoreutils-gui as then all the booleans are quickly available (like the boolean that turns on or off httpd's ability to send e-mail (or connect to a network socket, etc)). The booleans (at least most of them) are in EL5, but the interface isn't nearly as well documented (I know, many would like a TUI with the click boxes; maybe one is out there, maybe not; I'm not allergic to a remote GUI being available on a server).

The documentation for EL6 is better in this regard as well. But, really, if you're having an issue with httpd getting 'access denied' things, then you can simply: # getsebool -a |grep http

The booleans have reasonable, and readable, names that make sense, for the most part. Find the boolean that controls the feature you want, and use setsebool to set it to on.

It's not hard, and the admin overhead once you're used to it is a few seconds at most. It becomes another 'firewall-like' item to check off, really, as long as you do things at leat in a semi-standard way.

And ls-lZ is your friend, along with chcon. It is one more step, but, honestly, it's not nearly as big a step as firewalling (ipchains/iptables) was ten/fifteen years ago. At least not with EL6; but EL5U8 is better than EL5 GA was.

Wow, what a refreshing change. How nice it is to read a well balanced *informed* point of view on SELinux rather than the usual hysteria from those who can't be bothered to RTFM.

To get to the OPs original question - I'm guessing it's about the same percentage as the number of people who 10 years ago would turn off their firewall whenever they couldn't get something to work. Gradually over time they were convinced this was a bad idea and you needed a firewall. Likewise, you need SELinux so the sooner you get to grips with it the better. It's not *that* hard.