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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
