Extending generated SELinux policies

July 06, 2021

When we assign a different policy to a new application, we are reusing and possibly extending existing policies. We can go a step further and generate new policies, after which we can further extend those policies, effectively moving into the realm of developing new policies ourselves.

By using policy generation tools, however, we can quickly create a first-draft policy and adapt as needed.

An important caveat is that policy generation tools often limit themselves to a single-policy format, either being reference policy style or CIL style. Administrators and organizations should try to focus on a single style and stick with that so that the learning curve for new developers and administrators isn’t too high.

Understanding the limitations of generated policies

Policy generators, such as the udica tool often have a very specific purpose. For instance, the udica tool focuses on generating new container SELinux domains and is only useful for those containers. Generators will always have a specific target in mind for what their policies should look like.

The generated policies are often application-level policies. Creating fine-grained policies with generators is hard, and defining category-wide policies requires multiple steps and occurrences, whereas generators often use single-step generations.

Furthermore, most generated policies only generally support role-based access controls within SELinux: either a user is allowed the target SELinux domain and interacting with it, or the user isn’t allowed. Differentiating roles (such as application administrator versus application user) are not often included in generated policies.

Administrators should be aware that generators also have to make assumptions about how applications work. While this allows generators to be used for the majority of simple services and applications, they are definitely not ready yet to substitute a knowledgeable team of SELinux policy developers.

Introducing sepolicy generate

The sepolicy command is able to generate initial SELinux policy modules, which administrators and developers can then fine-tune further. This generator will use some resources on the system (such as the package database of the distribution) to better understand which resources to include, and generates a number of SELinux policy files.

As there are different types of applications around, the sepolicy generate command also requires the user to inform it about the application type. The following types are currently supported:

  • User applications are identified with the --application option. Such applications are meant for end users to launch and interact with.
  • System service applications are identified with the --init option. Applications that run in daemon mode or with their own user are most often system service applications.
  • D-Bus system service applications are identified with the --dbus option. This type of service is invoked by D-Bus.
  • Common Gateway Interface (CGI) scripts or applications are supported through the --cgi option. Using CGI-specific domains allows having CGI applications run in their own domain, rather than extending the privileges of the web server domain itself.
  • Internet services daemon (inetd) applications are supported through the --inetd option.
  • Sandbox applications are like user applications but much more confined, and are supported through the --sandbox option.

Next to application-level policy generation, sepolicy generate also supports generating user domains and roles:

  • Standard users with support for the graphical desktop can be generated using the --desktop_user option. This is a common, non-administration-oriented user role.
  • A more lightweight, minimal user role that still supports the graphical desktop can be generated using the --x_user option. This domain focuses on minimal permissions and thus requires further extensions before they can be better put to use.
  • If no graphical user interface needs to be supported, then you can use the --term_user option. This generates a confined user domain without desktop support.
  • Administration-oriented user domains can be generated using the --admin_user option. This is meant for broad administrative privileges.
  • More confined administration domains can be generated using the --confined_admin option. This allows you to generate user domains that have administrative roles for a limited number of application domains, not to the system as a whole.

The generator also supports customizing existing domains further (using --customize) or generating specific types (using --newtype).

Let’s use sepolicy generate to generate a policy for the pgpool-II application.

Generating policies with sepolicy generate

The sepolicy generate command will create a skeleton SELinux policy, using the reference policy code style. This policy can then be gradually extended with the privileges the application needs.

Let’s create and adapt the policy for pgool:

  • First, we tell sepolicy to generate a new policy, named pgpool, which is intended for the /usr/bin/pgpool binary:
# sepolicy generate -n pgpool --init /usr/bin/pgpool
  • Next, build the generated SELinux policy:
# make -f /usr/share/selinux/devel/Makefile pgpool.pp
  • Load the policy in memory:
# semodule -i pgpool.pp
  • Relabel the filesystem, or at least the locations mentioned in the generated pgpool.fc file:
# restorecon -RvF /usr/bin/pgpool /var/log/pgpool \
 /var/run/pgpool
  • Start the pgpool service:
# systemctl start pgpool

After starting, be amazed that pgpool is running flawlessly.

Now, you might have the impression that this was too easy. Yes, it was. The default SELinux policy that sepolicy generate provides is permissive, as you can see from within the pgpool.te file:

permissive pgpool_t;

If we remove this statement, rebuild, and reload the policy, then we will notice the failures coming up again, such as the process not being allowed to bind to the selected ports. We can now use audit2allow, for instance, to help us extend the policy as needed:

# cat /var/log/audit/audit.log | audit2allow -R

Gradually extend, rebuild, and reload the policy until the application works without problems.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur

0 Comments

Submit a Comment

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

5 × four =