Creating SELinux Policies Simplified

SELinux does not have to be as hard to manage as many people may think.
Getting and Installing SELinux

SELinux is included in many distributions nowadays, and even if it does not come with the main distribution, distribution-specific packages usually are available for popular distributions. The sources for SELinux are available from

Installation of seedit

seedit is a user-friendly Webmin-based tool that enables an administrator to administer SELinux policies from a Web browser. The seedit Webmin interface allows users to perform every action they can normally perform by writing manual scripts in m4 in a point-and-click environment.

seedit is available from

Once installed, the SELinux policy is located in $SELINUX/(seedit-something)/policy/policy.conf (where $SELINUX is the root directory of your SELinux installation—usually it is /etc/selinux/).

Let's familiarize ourselves with the seedit interface. Fire up a browser, point it to http://localhost:10000 and go to the System→SELinux Configuration section.

You will see six icons labeled configure ACLs, define domain transitions, define relationship between users and roles, create new domain/roles, delete domains/roles and update configuration.

Configure ACLs

Here you can define virtually all access control to nearly every object in the system. This includes allowing/disallowing read, write or executable files to entire directories or individual files and allowing/disallowing access to networking capabilities. In this section, you also can define ports in which the specific application can work. Let's say we assign port 80 to Apache; if it is started to work on port 81, SELinux terminates this process.

IPC access control can be defined in this section also. You can define what kind of IPC mechanism this particular application can use and with which applications the particular application can communicate.

Other access controls that can be defined in this section include various administrative access controls, such as kernel communication privileges, SELinux operations, process information retrieval and so forth.

Defining Domain Transitions

In the domain transaction section, you can define which processes can spawn the current application—for example, by default, the seedit policy defines this domain transition for MySQL: kernel→init→mysqld. This means the kernel can start init, and init in turn can launch the MySQL dæmon. If the application has a dæmon associated with it, domain transitions should be defined or the dæmon will never be able to start.

So in this section, the user can define domain transition, alter existing ones or remove them altogether.

Define Relationship between Roles and Users

Roles are privileges that an object (like users) can have on a system. For example, there may be a role that allows access to all files in the system. Thus, in this section, users can associate roles with specific users on the system.

The next two sections are self-explanatory. They allow you to define a new domain/role and remove a domain/role. Defining a domain/role is the first step when adding access control rules for a new application or user.

The last section is the update configuration section; it allows the user to update the policy and recompile it and load it.

seedit comes with a plethora of predefined policies, which cover every popular server/dæmon in a Linux system—from the kernel to the MySQL dæmon.

Defining a New Policy for a Dæmon Application

Defining an SELinux policy for a dæmon is an iterative process. The first step is to “register” the dæmon with SELinux, by declaring a domain/role in the seedit Webmin interface. This is done in the Add Domain/role section discussed previously. The convention is that domains should end with a _t, and role definitions should end with an _r. So, there could be a role, such as admin_r, and a domain, such as mysqld_t.

Defining domain transitions is another important step. Here you have to allow the parent processes of the dæmon to spawn the concerned dæmon. Usually if the dæmon activates at startup, you need to define a domain transition from init to the concerned dæmon.

Define the initial access control list for the dæmon. Now, it is not possible for the user to define an exhaustive ACL for the dæmon when it is initially installed, rather what is usually done is that an initial ACL list is defined, which is very restrictive. Every time the application tries to access an object and is not allowed to do so, an access violation message occurs; such messages can be accessed from /var/log/messages. As you use the dæmon, SELinux will report some violations. Considering that the dæmon for which we are trying to write rules is called foobar, the violation messages will look like this:

|avc: denied { write } for pid=7279 exe=/usr/bin/foobar comm=ifup
name=dhclient-eth0.conf dev=hda12 ino=57400
scontext=system_u:system_r:foobar_t tcontext=system_u:object_r:etc_t

This violation states that a write attempt was made to the file dhclient-eth0.conf by our application. This violation can be removed by giving the application write access to the dhclient-eth0.conf file. This violation can be addressed by going to the Configure ACL section of the seedit Webmin interface, under the File ACL section, and then browsing to the place where this file exists, and giving the application foobar write access to it.

Another violation might look like this:

|avc: denied { create } for pid=7279 exe=/usr/bin/foobar
scontext=root:system_r:foobar_t tcontext=root:system_r:foobar_t\

This violation reports that the application tried to create a UDP socket and was denied. To remove this violation, we can simply add networking features to the access control of the foobar_t domain. This can be addressed by going to the Configure ACL section and in the Network ACL section, selecting Allow Network for the domain foobar_t.

All access violations can be addressed in the Configure ACL section of the seedit Webmin interface.

After every policy update, reload it via the Update Policy option in the seedit Webmin interface and restart the dæmon. As other violations occur, update it again and so on, until you get nearly no violation messages.

There are other ways to generate access rules for an application with the help of audit2allow tool. But using it can lead to general rules, which can lead to security problems. You always can refine the rules the tool generates, however.

When creating or updating policies, make sure you have set your SELinux installation to permissive mode. SELinux has three modes: enforcing, disabled and permissive. In enforcing mode, all access controls are enforced according to the defined policy. In permissive mode, the policy is not enforced; however, violation messages are shown when any violation to the policy occurs. Disabled mode completely disables SELinux.

Irfan Habib is an undergraduate student of software engineering at the National University of Sciences and Technology, Pakistan. He has been deeply interested in Free and Open Source software for years.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot