On Sunday 28 November 2010 13:31:28 Benjamin Franz wrote: > Worse - it doesn't always log what it is doing in a way that you can figure > out. Occasionally not at all. SELinux does have some rate-limiting capabilities built-in to avoid a flood of identical messages...so the "triggering-event to log ratio" is not 1 to 1. I understand this may be confusing for troubleshooting purposes but you need to be aware of this. > Once because an update to SELinux changed the labeling on an existing > directory tree - blowing away my own applied labeling with no warning When you apply custom labels to files many people forget that if there's a relabel involved (via /.autorelabel or manual filesystem relabel) all your custom labels are gone UNLESS you update your local policy contexts by doing: semanage fcontext -a -t new_type_here 'regex_here' > I've had several instances of SELinux breaking a previously stable > system after an update to SELinux or its policies. On about the same > number of machines. The most recent within the last year. All our CentOS 5 servers have been running smooth with SELinux enabled. I can't tell from previous versions since I always disabled it (I was intimidated by it until I decided to take SOME TIME to read about it and UNDERSTAND it). Once you grasp the essentials isn't that of a big issue really. If you are running the packages that come with your distro and you leave the stuff in their respective places (/var/www/html etc), you shouldn't be doing much tweaking. In a nutshell, for me, when I suspect there is something related to SELinux involved I proceed as follows: 1) I'll check the logs to see if there's any AVC message. If there is... 2) I'll check if this is related to a mislabeled file. If it is, I'll fix the label. If the file in question is on a standard place...a simple restorecon should work but if the file is in another place (non-standard location) I'll need to register that as a local customization to the file contexts (with semanage fcontext...) 3) If the label is correct for the file I'll check if there's a boolean to control (allow/deny) this action (example: there are booleans to allow ftp server to serve from home directories or not etc...) 4) If there is no boolean and I'm 100% the access is needed...I'll create a local custom-policy with audit2allow. That's basically it. On the other hand, there are situations like, for example, our RHEL servers running Oracle databases. There's no way to run SELinux as Oracle won't support it. I heard they're working on it and in future versions they might support it (or maybe their current one I'm not sure). In other cases where we use Symantec Netbackup (the client installed on all servers) we just needed to change some labels on some specific libraries and that was all. Luckily this was well documented and there were some KB articles about this. There has been a lot of progress with SELinux lately. I think you should reconsider your position and perhaps give it a try on the upcoming CentOS 6 where the targeted policy is much matured. Best regards, Jorge