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
