Making Cobbler work with SElinux on CentOS / RHEL 6

By default, Cobbler will not work properly on a CentOS / RHEL 6 machine with SElinux enabled. The easy way out is to disable SElinux entirely, but I prefer to write a custom policy instead – it is not that difficult.

The basic approach is this:

  1. Use Cobbler as you normally would (you will trigger several SElinux denials, so expect errors)
  2. Extract the relevant SElinux audit messages; convert them into a local policy
  3. Load your local policy
  4. Repeat steps 1..3 until everything works as expected

First attempt: the “cobbler import” command fails; rsync cannot access files on the mounted DVD ISO. Time to start writing a local policy!

The following command generates a basic SElinux policy from the SElinux audit messages:

  cat /var/log/audit/audit.log | audit2allow -l -v -m local > local.te

The resulting local.te file (ASCII, open it in your favorite editor) will list various items, some if which are not related to the Cobbler / Rsync operations. Edit the file to taste. Now, compile and load that policy:

  checkmodule -M -m -o local.mod local.te
  semodule_package -o local.pp -m local.mod
  semodule -v -i local.pp

Note: every invocation of “audit2allow -l” will overwrite your local.te policy file with new events since the last time a policy module was loaded. This is why you should keep backup copies of the previous versions so you can merge new events in with the existing ones.

In the end, you will end up with a policy in local.te like this:

module local 1.0;

require {
    type cobblerd_t;
    type cobbler_var_lib_t;
    type iso9660_t;
    type public_content_t;
    type rpm_var_lib_t;
    type rsync_etc_t;
    type security_t;
    type tmp_t;
    class capability { sys_module fsetid };
    class dir { add_name create getattr open read remove_name rmdir search write };
    class file { create getattr open read unlink write };
    class lnk_file create;
    class unix_dgram_socket create;
}

#============= cobblerd_t ==============
allow cobblerd_t cobbler_var_lib_t:lnk_file create;
allow cobblerd_t iso9660_t:dir { open read search getattr };
allow cobblerd_t iso9660_t:file { open read getattr };
allow cobblerd_t public_content_t:dir { write rmdir remove_name };
allow cobblerd_t rpm_var_lib_t:dir { open read search getattr write };
allow cobblerd_t rsync_etc_t:file create;
allow cobblerd_t security_t:dir read;
allow cobblerd_t self:capability fsetid;
allow cobblerd_t self:unix_dgram_socket create;
allow cobblerd_t tmp_t:dir { add_name create remove_name rmdir write };
allow cobblerd_t tmp_t:file { create getattr open read unlink write };

Tip: Fedora 14 and Dropbox

The current version of Dropbox does not behave nicely on Fedora 14 – the Dropbox update daemon attempts to execute code from stack. This is prohibited by SELinux (and rightly so).

There is a workaround (taken from the Dropbox Support forum):

  /usr/bin/execstack -c ~/.dropbox-dist/_ctypes.so

Let’s hope that Dropbox releases a proper fix for this problem soon.

The trouble with setroubleshootd

Pop quiz: what is wrong with this picture?

     top - 17:15:07 up 5 days, 17:35,  1 user,  load average: 3.76, 4.97, 3.18
     Tasks: 135 total,   2 running, 133 sleeping,   0 stopped,   0 zombie
     Cpu(s):  0.0%us,  0.5%sy,  0.0%ni, 52.3%id, 47.2%wa,  0.0%hi,  0.0%si,  0.0%st
     Mem:   2097152k total,  2088744k used,     8408k free,     2564k buffers
     Swap:  1048568k total,   946156k used,   102412k free,    45548k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
     1507 root      15   0 1987m 1.2g 2824 S  0.3 62.3   1096:21 setroubleshootd

The system was under severe memory pressure. This caused huge amounts of IO-Wait and slowed the system down to a crawl.

According to top,  setroubleshootd is using 1.2GB out of a total of 2GB of RAM. This is ridiculous. The daemon basically only checks for SElinux-related audit messages and displays a dialog informing you of the event. Why does it need to use more than 60% of physical memory on my system?

As far as I can tell, there’s no real need to run this daemon. Probably only on a graphical workstation, but not on a server.

     chkconfig setroubleshootd off
     service setroubleshootd stop

Problem solved ;-)

This was not an incident; a quick “ps aux |grep” confirmed that setroubleshoot was using a lot of memory on most systems:

     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
     root      2926  3.0 13.0 545672 317292 ?       Ssl  Nov11 265:09 /usr/bin/python -E /usr/sbin/setroubleshootd

     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
     root      3107 11.9 48.5 1664092 1437740 ?     Ssl  Nov11 1033:51 /usr/bin/python -E /usr/sbin/setroubleshootd

     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
     root      1503 13.7 74.7 2524604 1566892 ?     Ssl  Nov11 1187:44 /usr/bin/python -E /usr/sbin/setroubleshootd

These are all RHEL / CentOS 5.5 systems, 64-bit with latest updates installed…

Configuring SELinux for WordPress

I recently installed WordPress 2.9.2 on my webservers.

Since these servers are obviously connected to the Internet, they run with SELinux enabled. This means that you cannot use the standard FTP functionality in the WordPress admin panel to manage your themes and plugins.

If you configure SELinux properly, you can enjoy the comforts of WordPress without compromising security.

Continue reading “Configuring SELinux for WordPress”