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
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.
- User applications are identified with the
--applicationoption. Such applications are meant for end users to launch and interact with.
- System service applications are identified with the
--initoption. 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
--dbusoption. This type of service is invoked by D-Bus.
- Common Gateway Interface (CGI) scripts or applications are supported through the
--cgioption. 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
- Sandbox applications are like user applications but much more confined, and are supported through the
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_useroption. 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_useroption. 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_useroption. This generates a confined user domain without desktop support.
- Administration-oriented user domains can be generated using the
--admin_useroption. This is meant for broad administrative privileges.
- More confined administration domains can be generated using the
--confined_adminoption. 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
sepolicy generate to generate a policy for the pgpool-II application.
Generating policies with sepolicy generate
- First, we tell
sepolicyto generate a new policy, named
pgpool, which is intended for the
# 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
# restorecon -RvF /usr/bin/pgpool /var/log/pgpool \ /var/run/pgpool
- Start the
# 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
# cat /var/log/audit/audit.log | audit2allow -R
Gradually extend, rebuild, and reload the policy until the application works without problems.