Project:SELinux/Development policy

Developing a set of security rules is or should always be done with a common set of principles and rules in mind. This document explains the policy used by Gentoo Hardened in order to consistenly develop its security policy rules.

Rationale
SELinux policy rules are used to confine applications, potentially restricting their use on a system. The rules are made to be managed by a security administrator, someone (or a group of people) who was the final say in how a system should behave. Due to the flexibility of SELinux policy rules, various different implementations exist. One can have SELinux rules allowing everything an application does, or rules that allows everything an application needs to function properly - or somewhere in between. You can confine parts of an application, or confine a group of applications. You can allow all roles to execute applications, or only a few.

In short, SELinux policy rules allow you to define the security access rules just the way you want them to be - and that's perfect. That's exactly what makes SELinux this interesting.

The problem however is that a distribution such as Gentoo Hardened offers a set of rules for a large set of users. As such, it needs to take certain decisions itself on how it defines the SELinux policy rules. And to help the developers in writing the policy rules, the same set of principles and guidelines should be followed to offer the end user an integrated, consistent set of SELinux policy rules.

That set of principles and guidelines can be found in this document. Note that this is still subject to change. For instance, if Gentoo Hardened gains sufficient developer resources it might change some principles, resulting in a change of policy.

Principles
This policy is based upon the following set of principles. Note that principles do not mean that they are to be considered mandatory. They guide us in our definition of the policy and in handling of future events.

No Role-Specific Domains
The reference policy development method supports the use of role-specific domains (like staff_mozilla_t versus user_mozilla_t ). These domains are generated automatically the moment you assign the necessary template(s) to the roles.

Although this offers a great deal of flexibility (you can have different access controls for different roles) and a more strict segregation of access controls (no single SELinux rule that potentially allows one role to influence the resources in the domain of another role, even if the real user is the same), it is more difficult to manage. Also, its flexibility already implies that the security administrator of the system customizes Gentoo Hardened's policy.

For this reason, Gentoo Hardened will not create role-specific domains by default. Exceptions are always possible. For instance, the screen_t domain uses role-specific implementations ( staff_screen_t ) because the domain needs to transition back to the caller ( staff_t to staff_screen_t which launches a shell or command in the staff_t domain).

Do Not Allow Cosmetic Denials
When developing SELinux rules, the Gentoo Hardened SELinux developers will implement the access permissions needed for an application to function properly on their system. Additional rules are then added based on testing, feedback and thorough analysis. A SELinux developer will never implement an access permission without being confident that it is needed to allow the application to function properly.

Instead, if a denial is given but seems to be cosmetic, the Gentoo Hardened SELinux developer will use dontaudit statements.

Only Reference Policy Suggested Roles
Gentoo Hardened will not create and maintain additional roles. We will limit the supported roles to those offered and actively maintained by the reference policy.

Even though it is very simple to create roles for specific functions on your SELinux systems, it is hard for a generic policy to create new roles that fit the needs of most. We assume that, if there are such roles, then they are managed and maintained by the reference policy.

Name SELinux Policy Packages After Their Module
SELinux policy packages should be called after the module they implement (and not the Gentoo package for which the policy would be implemented). The name should use the syntax.

By using the upstream module name, we ensure that no collisions occur (neither package name collisions as well as file collisions during installations) and follow upstream strictly. It also keeps the naming of the packages clean.

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Sven Vermeulen