[colug-432] SELinux == Sadness

[R P Herrold]

On Sun, 25 Apr 2010, Jeff Frontz wrote:

> My experience with SELinux has always led me to disable it
> immediately.  Does anyone actually leave it on in a production system
> (and by "production system", I mean one that-- when it goes down-- has
> your CEO immediately and actively monitoring every one of your bodily
> functions until the system is up and running normally again)?

yes -- always, all production boxes; and I am not alone as I 
know that one of the US CentOS devels who work for the Army 
follows the same practice. We ship it enabled on the PMMan 
product and count on it as part of our protection tools for 
third-party customers' data, SAAS, and un-managed instances.

As I think of it, I've not been asked to disable it on behalf 
of any customer.  It is a mature enough technology that the 
time to beef about SELinux has passed, and the sysadmins need 
to buckle down and learn it

> Having an arcane piece of software suddenly decide that it doesn't
> really want that process to write to /tmp or consume a bit more memory
> or use the CPU or have a PID-- right in the middle of that critical
> movement of the robot arm or the database update for the quarterly
> financial reports to the SEC-- call me crazy, but I don't really need
> that help, thanks.

It is no longer 'arcane' -- it is part of kenel mainline.

What this says to me is that there is a defect in the test 
coverage, and root cause fault analysis, or at your 
pre-deployment staging bench in not spotting and solving these 
issues before deployment.  One time it may be permissible to 
relax SELinux to 'get the fire breathing boss off your back', 
but if you don't write the bug report, and solve it before 
the next quarter's run, the problem is not the tool

> Am I just ignorant of how to configure it?  [that's a partially loaded
> question-- if you answer "yes", you'll surely be contacted about
> giving a talk at some upcoming COLUG meeting]

Yes, it would seem, although I would not use that term.

Rather I would say, that SElinux and RBAC are complex areas, 
and the tools to allow an end admin to 'see' the problems, and 
to know the fix have been slow to become friendly.  As such a 
'cottage industry' of tactical fixes and content findable to 
Google have cluttered the result sets one finds.  The answer 
is simple.  Read the primary sources content first, and look 
at the date and consider quality of any writeup one is 
reading.  If it is from a 'hater', or a 'I'll start by turning 
it off' person, you dont want to read any further, as they are 
not willing to use the tools provided for diagnosis, 
debugging, and remediation

There are dedicated mailing lists on the development and usage 
of SElinux; Dan Walsh particularly is enormously helpful as 
one of the lead SElinux developers who also responds to well 
reported bugs with fixes particularly on RHEL shipped daemints 
and tools, almost immediately.  The SELinux developers present 
regularly at industry events and are prefectly approachable 
'out of band'

The auditd and the log it produces in /var/log/audit/ is 
parseable by readily available tools, so that one can build 
(often in an incremental basis on the build bench as one is 
testing) the rule set (checking intermediate work product in 
the version control sustem, and noting such in the comment 
journal of the bugzilla tracker) to set that application that 
'has to run' be surveyed and inventoried as to its local 
unique requirements.  The rules generated are in simple text 
form, and post-processed and folded into the binary form that 
the SElinux modules actually work from.

The tools of bug trackers and VCS are basic, but people want 
to talk about problems on mailing lists and carp in blog posts 
instead.  This says something about the the authors.  I'd 
rather write tips and read content from people who are even 
more skilled than I.  [That said I enjoy writing a good 'rant' 
post as much as the next person, but I try to balance it with 
a worthwhile one as well.  Looking at my compose drafts queue, 
I see several I need to finish and release of each type ;) ]

-- Russ herrold