Building modules for SELinux to allow specific actions. This also covers the basic concept(s) of testing if SELinux is the culprit.


To be able to load the module into the kernel you must be root and be in root’s home or a subdirectory theirof. Also, there are packages you need for building the modules. It is also recommended you use “auditd”. The main package you will need to build the modules is “checkpolicy”.

To install auditd:

To start and set auditd to start on boot:

Make Sure You Are Root

The best way to work with SELinux is from the home directory of the root user. A good practice is to keep the policies you have created and loaded in a central location for later review and/or updates. While logged in as root, do the following to create a central location for working with the SELinux modules:

This will create the directory /root/selinux and change to that directory for building and storing the policies.

Understanding What You Are Doing

To complete the audit correctly you must understand what you are trying to allow. This doc is not for the new users that have no idea what SELinux is or how it works. Please understand what you are doing and why. Never assume the policy built is what you expect. Audit messages can sneak in and really screw up your security. Please do not take building modules lightly. Do the research and understand what you are doing. If you do not agree that you understand what you are doing, do not continue. Not all issues should be solved by building SELinux modules. The issue could be fixed by doing something as simple as ‘chcon’ing the files trying to be accessed. Read before you assume. Also, check if SELinux is even the issue by putting SELinux in Permissive mode and checking to see if the issue goes away. To test if SELinux is really the issue do the following:

If the issue(s) you are having go away, it seems that SELinux is causing them. Set SELinux back into Enforcing mode and continue:

Auditing Concepts

The concept we will be using it to set SELinux into permissive mode to allow for the actions to take place but to audit or ‘log’ what SELinux would have denied. Audit messages can show up in multiple locations. By default, they will show up in /var/log/messages. In this howto we will be assuming that auditd is in use and the audit log will be located in /var/log/audit/audit.log. If you don’t have auditd installed or don’t want to use auditd, replace all /var/log/audit/audit.log instances with /var/log/messages. It is recommended to use auditd.

Doing the Work

This work should be done from the /root/selinux directory. It is only a recommendation and most of the work could be done from other locations. However, you might run into issues when loading the module depending on where the module is stored.

  1. Set SELinux into Permissive mode:
  2. Load the SELinux policy again to give us a ‘reset point’ that will help isolate the exact actions that need to be allowed:
  3. Trigger all the actions that need to be allowed. As SELinux is in Permissive mode, you will be able to do the action(s) that has been denied. Make sure you trigger all actions that need to be allowed.
  4. Build the module from the audited actions:
  5. After you have audited the actions, set SELinux back to Enforcing mode:
  6. Inspect the module that has been built. Understand what the module will allow before you load it. Use your favorite editor to view the module policy or use ‘cat’ as in this example:
  7. Load the module into the kernel:


A  common problem is on ‘semodule -l moduleName.pp’ you get a “can not read file moduleName.pp” or similar message. This is because SELinux is doing it’s job and not allowing modules to be loaded from anywhere. The best way to avoid this issue is to use the /root/selinux directory.

To check what modules and their versions are loaded do the following:

It is recommended you read all the man pages on the commands being used. It is also helpful to read the additional man pages listed. It will help you understand what is going on and why. The following are recommended man pages to read:

More Information


We test this stuff on our own machines, really we do. But you may run into problems, if you do, come to #centos on

Added Reading

  • SELinux FAQs

    These are a must read to understand what SELinux is and how to work with it.
Last Modified: 17 Oct, 2010 at 03:36:28