[CentOS] SELinux threads, cynicism, one-upmanship, etc.

Wed Nov 16 20:12:53 UTC 2005
Lamar Owen <lowen at pari.edu>

After reading through the various SELinux threads, I really became quite 
perturbed.  I mean, really quite perturbed.

As an IT Director (and the entire IT department, currently), if I were hiring 
a sysadmin I know for a fact that someone whose first response to a question 
on why something doesn't work is 'turn it off' would not get a job here.

Neither would a sysadmin with as much cynicism as has been displayed, or an 
automatic 'it broke things' when something new (and in fact improved) comes 
along get a job here.  Do realize that this list is archived, and that many 
people who are hiring might use Google to find your name (or mine, for that 
matter).

No, I would hire someone who would read enough of the friendly manual to know 
where to look and who to ask to find the fix for the real problem.  The real 
fix is there; thanks to the KMail developers for including a 'mark as 
important' feature so I can find that message amongst the drivel in that 
thread easily (well, actually I'll probably just delete everything but the 
real solution).  

It is the lazy sysadmin who just turns things off without an understanding as 
to why they are turned off; don't give me the 'overworked' line; you had 
enough time to post here on the brokenness of SELinux, so you had enough time 
to find the problem's real source.  I am not interested in hiring lazy 
sysadmins, once I get to hiring.  Bryan Smith, for all the verbosity he is 
known for, doesn't seem to be lazy and could likely hold the job; Craig White 
likewise, among many others here.  I won't name all the names to protect the 
guilty. :-)

The main reason I think sysadmins in general seem to hate SELinux is the 
'Mandatory' part of 'Mandatory Access Control' : that is, superuser power is 
too addictive to get rid of, and SELinux can do away with 'superuser' powers 
entirely.  AND THAT IS A GOOD THING.  Yes, it really is.  The buffer overflow 
exploit for those root-running daemons doesn't stand a chance even if it 
gains root, as long as the selinux policies are set properly.

And, yes, it is possible to set the policies properly; any daemon whose 
developers feel that it needs to be exempt from such might have a problem 
running on my servers.  

In a nutshell, SELinux is on and enabled everywhere here; I can't seem to find 
any measureable speed difference between SELinux targeted, permissive or off;  
it is unobtrusive in my experience, and it does indeed help protect 
internet-facing systems from unknown buffer overflows.  This is a good thing, 
and I am convinced that the minor inconvenience of learning a new security 
tool's configuration is a great tradeoff; especially when the alternative is 
a compromised system.  As there is no such thing as a 100% secure system, 
anything that improves security but, when properly configured, doesn't impact 
usability is a BIG WIN in a my book, and probably in many other IT Directors' 
books too.

I have been running Red Hat Linux on internet-facing servers for quite a 
while, now, and in my opinion and experience, SELinux is the best thing to 
happen to Linux since 0.13 was released.  It's about time the antiquated 
default Unix permissions system was overhauled.  Yes, it requires study, 
thought, and care.  I would expect nothing less of any sysadmins who would 
work under me.

Also, as one poster wrote, SELinux is NOT a *service* but is indeed the Bully 
Boss of the system.  This is also a good thing for internet-facing servers to 
have; how is the machine supposed to know that the Real Root has logged in, 
and that that process with euid 0 really was started by the Real Root?  

The Real Root should take the time to configure in to the policies those 
things the Real Root would normally do (you know, things like backups and the 
like, along with other normal activities), but then block those actions that 
the Real Root would not do (like install a rootkit; yes, a properly 
configured SELinux can prevent installation of a rootkit on your machine even 
if it gets 'rooted').  The power of the properly configured Mandatory Access 
Control system (The Bully Boss) is completely in the control of the Real 
Root, but untouchable by those Fake Roots who wish to do your system harm.  

This is again a good thing, and one I would think Diligent Sysadmins would be 
falling over themselves trying to learn and deploy.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu