Gentoo Hardened SELinux Development Policy
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
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
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
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 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.
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.