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