CentOS - Apr 2012 - selinux on/off percentage

hi

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



thanks.

min

On 03/31/2012 11:31 PM, Min Wang wrote:
> hi
>
>      Just wondering if there is any statiscs report of selinxu usages in
> production environment? I know some still turn it off.
>
>
>
> thanks.
>
> min
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
I don't know about any general statistics, but I do know that I have it 
turned off on my desktop/file server/print server/samba server.

-- 
     _
    ?v?
   /(_)\
    ^ ^  Mark LaPierre
Registerd Linux user No #267004
www.counter.li.org
****

On almost all servers that I have SELinux is turned on in enforcing more.  For
desktops I don't have it turned on at all.  I work in a research environment
and managing SELinux in the context of research is very difficult.  I can think
of one *maybe* two servers that don't have it in enforcing because it runs
some really old legacy code that would take months to figure out.

----- Original Message -----
| hi
| 
|     Just wondering if there is any statiscs report of selinxu usages
|     in
| production environment? I know some still turn it off.
| 
| 
| 
| thanks.
| 
| min
| _______________________________________________
| CentOS mailing list
| CentOS at centos.org
| http://lists.centos.org/mailman/listinfo/centos
| 

-- 
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax     : 778-782-3045
E-Mail  : jpeltier at sfu.ca
Website : http://www.sfu.ca/itservices
          http://blogs.sfu.ca/people/jpeltier

Success is to be measured not so much by the position that one has reached
in life but as by the obstacles they have overcome. - Booker T. Washington

On 03/31/2012 10:31 PM, Min Wang wrote:
> hi
>
>     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.

The thing that SELinux is going to do is to prevent things from running
outside the proper contexts.  This means that it will, for example,
block known PHP exploits even though the machine is vulnerable, etc.

For machines not serving content, you can turn it off there if you want.

Here is a good FAQ about SELinux:

http://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/

And more info:

http://selinuxproject.org/page/Main_Page



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20120402/6b5b3607/attachment-0003.sig>

On Mon, Apr 2, 2012 at 5:28 AM, Johnny Hughes <johnny at 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.

-- 
   Les Mikesell
     lesmikesell at gmail.com

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 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 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.