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.

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.

Work As-Is

Confined applications should still function properly. Gentoo Hardened users who find that the policy is preventing the application to function the way it is meant to work by its developers should be able to consider this as a bug in the rules

Hide the Complexity

The complexity of the SELinux policy rules offered by Gentoo Hardened should be hidden from a regular user/administrator. This includes hiding denials that are considered to be harmless / cosmetic.

Keep It Simple

Simplicity is better. A set of rules, domains, types or roles that is easy to describe is easier to manage.

Be Reluctant to Trust

Applications or resources that can be influenced by untrusted actors should be individually protected. As such, they should not run in a common domain.

Least Privilege

Access privileges should be given on a need-to-have basis. No more, no less.

Track Upstream

When relying on external rules (such as offered from the reference policy) we strive to configure those rules to fit our needs or, if enhancements are needed, ensure that they do not interfere with the upstream rules - now or in the future

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).

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 optional dontaudit statements until sufficient testing (or inclusion upstream) warrants the messages to be hidden fully: the dontaudit rule is managed by a boolean called gentoo_try_dontaudit. If enabled, the AVC denials will be hidden using the SELinux standard dontaudit statements.

This ensures that, if a user feels that the access enforcement is wrongly denying particular access but is not showing it, he does not need to disable all dontaudit statements immediately to verify: he can first switch off the Gentoo Hardened-specific statements, which should limit the amount of denials he suddenly gets in his audit logs and only shows those managed by Gentoo Hardened.

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.

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 sec-policy/selinux-<modname> 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.