Understanding SELinux, Part 6

In Part 5, we looked at logging SELinux tasks and deciphering them using various methods—most notably auditd and setroubleshoot RPMs. We learned that we can easily fix minor errors involving by Boolean values and/or changing the types of certain files by using commands like setsebool and chcon/restorecon.

But what about allowing a certain set of actions that are, by default, denied by the default targeted policy? What if we really want files of tmp_t to be accessed by the httpd daemon due to certain requirements in our work environment? What if we wanted to install our own applications and daemons while still maintaining the security provided by SELinux? What if we run an Oracle database on our RHEL server, which is exposed to the Internet—because that is its intended use?

What about the whole concept of open source, freedom and the ability to modify applications to suit our needs rather than we modifying ourselves to suit the application’s needs?

Thankfully, SELinux gives us the power and complete freedom to achieve all this. There are two ways in which we can approach the whole concept of customising SELinux:

  1. Modifying the source of the policy (easily available through source RPMs).
  2. Developing modules that can be compiled and loaded along with the base policy.

For beginners, intermediate-level users and also for production purposes, I would not recommend the first option unless it is absolutely necessary. It requires more in-depth knowledge and experience to modify the core policy—we will take a look at this option in a later part of this series.

For most of us, the second option of building policy modules will suffice. It is an easier approach and also lets us develop a better understanding of the SELinux policy language before we delve deeper into it by modifying the core policy.

Customising the default policy — Power to the people

As discussed above, we will customise the default targeted policy by adding our own modules. To do so we will use the semodule command.

semodule is the tool used to manage SELinux policy modules, including installing, upgrading, listing and removing modules. It is installed by the policycoreutils RPM. The man page, as usual, gives further details and helpful instructions on how to use the command.

Listing SELinux modules

To list modules, use the following:

[root@vbg ~]# semodule -l

If you execute this command on a freshly installed system with SELinux enabled, you will see a list of modules. A sample output on my system follows:

[root@vbg ~]# semodule -l
amavis  1.1.0
ccs     1.0.0
clamav  1.1.0
dcc     1.1.0
evolution       1.1.0
iscsid  1.0.0
mozilla 1.1.0
mplayer 1.1.0
nagios  1.1.0
oddjob  1.0.1
openoff 1.0.0
pcscd   1.0.0
pyzor   1.1.0
razor   1.1.0
ricci   1.0.0
smartmon        1.1.0
tmp     1.0.1
vbg     1.0.3

What this means is that the default SELinux installation does come with some modules loaded that are not part of the base policy. Looking more closely into the output of the above command, we see that in my system there are 18 policy modules installed. Each row of the above output corresponds to a policy module.

The output of the semodule -l command gives us two columns of information: Module Name and Module Version. Thus we can see that the amavis module has a version number of 1.1.0 whereas the vbg module has a version 1.0.3.

Also, these are the modules currently loaded into the memory and are active along with the base policy. But, where are these modules located? What difference do they make to the overall SELinux policy? How are they loaded and removed?

Let’s try to answer the above questions, one by one.

These are binary policy modules that, by default, have a file extension of .pp (Policy Package). Generally, the module name and the file name is kept the same, though it’s not mandatory. Therefore, we need to look up a file named amavis.pp (Policy Package for the Amavis daemon). By default, the location of this file is /etc/selinux/targeted/modules/active/modules/. If you go into this folder and list the contents, you will see the policy package files of all the currently loaded modules.

The policy modules obviously make a lot of difference. That’s what they were created for. To observe the difference they make, let’s use the wonderful seinfo tool discussed earlier.

To get an overall idea of the SELinux policy currently loaded, we shall use the command seinfo. A sample output from my system is shown below:

[root@vbg modules]# seinfo

Statistics for policy file: /etc/selinux/targeted/policy/policy.21
Policy Version & Type: v.21 (binary, MLS)

   Classes:            61    Permissions:       220
   Types:            1516    Attributes:        148
   Users:               3    Roles:               6
   Booleans:          211    Cond. Expr.:       187
   Sensitivities:       1    Categories:       1024
   Allow:           82576    Neverallow:          0
   Auditallow:         28    Dontaudit:        5086
   Role allow:          5    Role trans:          0
   Type_trans:       1400    Type_change:        17
   Type_member:         0    Range_trans:        23
   Constraints:        47    Validatetrans:       0
   Fs_use:             15    Genfscon:           64
   Portcon:           264    Netifcon:            0
   Nodecon:             8    Initial SIDs:       27

We can see that there are 1,516 types and 82,576 allow rules being recognised by SELinux. You can redirect this output to a temporary file just for comparison, later. You could use the following command:

[root@vbg modules]# seinfo > /tmp/org-selinux-policy

Let’s now remove one of the loaded modules. As an example, let us remove the amavis module.

Pages: 1 2 3


  1. Sandeep Mittal says:

    It is very helpful to me. 

  2. Ankur says:

    Really nice explanation. Thanks a lot.

Leave a Reply

Your email address will not be published. Required fields are marked *