Thursday, June 04, 2009

CentOS Kernel upgrade breaks SELinux

So last night I did a yum update on one of our web servers which included a kernel update.  All went well until the reboot at which time SELinux was preventing httpd from starting.  Dropping SELinux into permissive mode (setenforce permissive) allowed httpd to start and things went well except for the banter of SELinux messages in my logs bitching about one thing after another.  At first I thought about a system-wide relabel of the drive…but I’m truthfully a bit concerned that the hammer approach might break too many things.  After some research on the web I took this approach instead:

  • Grep out the line items from /var/log/messages that seem to be creating a problem. I ran something like: tail /var/log/messages | grep avc > fix1
  • Use the audit2allow script to build a file of fixes that could be applied to SELinux (audit2allow –M fix1a < fix1).  This creates a file called fix1a.bb.
  • Run fix1a.bb against the semodule command (semodule –i fix1a.bb)

That’s it.  I had to do this a few times as errors popped up, but it seems to have fixed the problem.   Be sure to read through the offending lines in the messages log to verify that things that are being denied should actually be working.

Here is an example of some of the errors I was getting:

Jun  4 16:15:45 MY-WEB01 kernel: type=1400 audit(1244197545.492:6268): avc:  denied  { append } for  pid=10103 comm="httpd" path="/var/log/httpd/access_log" dev=dm-0 ino=851362 scontext=root:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=file

Jun  4 16:12:29 MY-WEB01 kernel: type=1400 audit(1244112349.412:6262): avc:  denied  { search } for  pid=9737 comm="httpd" name="mysql" dev=dm-0 ino=851641 scontext=root:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir

I’m still in favor of SELinux although I think I’ll be taking more precautions (like snapshoting  a machine) before I update kernels.  Once I got past the errors I restarted SELinux (setenforce enforcing).

3 comments:

danwalsh said...

file_t means that you have a file on your system without a label. You really should make sure the labeling is correct.

fixfiles restore

will relabel your entire system

Or you could touch /.autorelabel; reboot to relabel on the next reboot.

Rolfsa said...

Thanks Dan. That is actually in the plan. I was looking to see if there was a way to save/restore the existing filelabeling information in case the systemwide relabel breaks something. The best I have found so far is piping a recursive ls -Z to a file so I have a record of what exists currently. I wish there was more up to date documentation on SELinux as the common stuff to reference was all created a few years back.

In any event, thanks for your feedback.

Rolfsa said...

Hey Dan...I found your blog which was a great help to me. I even gave you a shout out on my blog.

Thanks again.