SELinux on Xen

From PrgmrWiki

With most VPS SELinux has been disabled, but because you can configure your own kernel on a VPS, you can configure it to run SELinux and thus help to reduce the likelihood of your server getting hacked.

Setting up SELinux on CentOS 5

  1. Pull down the latest kernel with "yum install kernel-xen" and tweak /boot/grub/menu.lst to make your new kernel the default.
  2. Do a "yum update" to pull down all the fixes
  3. Pull down the selinux odds and ends with "yum install system-config-securitylevel-tui selinux-policy-targeted policycoreutils"
  4. Run "system-config-securitylevel" and set it to "permissive" and then hit "Customize" to configure iptables as you like it. Then press OK and OK to save.
  5. Check you have a file called /etc/sysconfig/selinux. It should include a line saying "SELINUX=permissive" and another saying "SELINUXTYPE=targeted". If needbe create and/or modify these lines.
  6. Run "touch /.autorelabel" to have the filesystem relabelled on the next reboot.
  7. Reboot with a "shutdown -r now". On reboot the filesystem will be relabelled according to the targeted policy. Machine will reboot when done.
  8. Log in again and do "cd /; fixfiles restore" to complete relabelling as for some reason some files got left behind. Run "sestatus" to check that SELinux is enabled and in permissive mode.
  9. Check /var/log/audit.log and make sure that it's stopped complaining about AVC denials. If needbe relabel any mislabelled files and use audit2why to figure out if something needs fixing.
  10. Once happy edit /etc/sysconfig/selinux again and change "SELINUX=permissive" to "SELINUX=enforcing" and reboot. Run "sestatus" again to confirm SELinux is now in enforcing mode.

In case of problems use grub to edit the kernel command line to add "selinux=permissive" or "selinux=disabled" - this will allow the system to boot and so get you in to fix the problem.

Tweaking SELinux

Sometimes SELinux will disallow actions that you want to have happen because the supplied policy doesn't quite do what you want. Thankfully it's fairly straightforward to modify it to suit your ends.

SELinux is often disabled because it seems to get in the way of your services. Like permissions, it's best to get SELinux set correct rather than disabling it entirely and throwing away an extra level of security.

Is SELinux the problem?

Error messages for SELinux on CentOS are stores in /var/log/audit.log. You can temporarily turn SELinux off using "setenforce 0" and back on again with "setenforce 1" - allowing you to see if SELinux is preventing the access.

Is the file context set correctly?

Every file, directory and symlink is associated with a security context, and most of the time the daemon restorecond will set it correctly according to the path. Sometimes files can become incorrectly labelled, or you may need to manually change the file labels if you keep files in a non-standard location.

You can query file contexts with ls -lZ and change them with chcon context file

For example, I keep my PostgreSQL databases in different directories (tablespaces). I check the context of the default location with ls -lZd /var/lib/pgsql/data and change the tablespace location to match with chcon system_u:object_r:postgresql_db_t:s0 /home/user/pgsql

To serve web content out of a non-standard location you could set the context with "chcon -R system_u:object_r:httpd_sys_content_t:s0 /path/to/directory", substituting the context with "system_u:object_r:httpd_sys_script_exec_t:s0" on script directories.

Warning! Your custom file contexts will be lost on a full relabel. For ultra-permanent changes you may wish to look at the files in /etc/selinux/targeted/contexts/files/*

Will a boolean help?

Certain common requirements can be enabled by setting an SELinux boolean. CentOS has around 200 booleans for commonly-requested optimisations which can be enabled and disabled on the command line. getsebool -a will list them all, or there's a more useful list with explanations.

For example, if I want my Apache to connect to my database over TCP/IP instead of local sockets, I can use setsebool -P httpd_can_network_connect_db 1 to enable permanently (-P) enable the httpd_can_network_connect_db boolean.

More exotic changes: a local module

Having found the AVC denial error in /var/log/audit/audit.log, save it into a file called local.err in a convenient directory. The command audit2allow can interpret an error message and use it to write a policy module that would prevent the error. Clearly this must be used with caution but can be very handy. audit2allow is operated using audit2allow -M local.pp < local.err which produces the policy file local.pp. This is then inserted into the kernel with semodule -i local.pp.

You can insert several modules, each with different names, to cover all your requirements and load and remove them individually using semodule.