Project:SELinux/Development policy

From Gentoo Wiki
Jump to: navigation, search

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.

Principles

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.

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 process of applying changes made available upstream on our repository

SELinux Domains

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.

Develop desktop policies

The project will focus development on the desktop area as well. With this, we hope to create a more secure desktop environment where potential vulnerabilities in application platforms do not automatically lead to the exposure and information leakage of user documents.

This will be facilitated through support of the XDG Base Directories in the SELinux policies, and a flexible user content management selection through SELinux booleans.

Isolate context definitions

We strive to have the context definitions for an application to be part of the SELinux module. That also means that base definitions, like bin_t and lib_t as best positioned inside the file context definition of the module (unlike what the reference policy requires, which is to have those made part of the modules that define those types).

Domain-scope permissions

If permissions can be assigned to an application domain, support this through both an attribute-based approach as well as direct assignation.

For instance, for attribute-based:

CodeAssigning an attribute to a domain

interface(`test_logger_domain',`
  gen_require(`
    attribute testloggerdomain;
  ')
  typeattribute $1 testloggerdomain;
')

For direct assignation:

CodeAssigning privileges directly

interface(`test_logger_domain_privs',`
  gen_require(`
    type test_log_t;
    type test_t;
  ')
  allow $1 test_t:process signal_perms;
  allow test_t $1:process signal_perms;
  
  allow $1 test_log_t:file append_file_perms;
')

The privileges in direct assignation can be assigned to the attribute then:

CodeGranting privileges to the attribute domain

attribute testloggerdomain;
  
test_logger_domain_privs(testloggerdomain);

The use of this allows for attribute-based privileges on other domains, but also to assign this if the permissions are triggered through booleans:

CodeOptionally enabling permissions

# Outside tunable
test_logger_domain(foo_t)

# Inside a tunable
tunable_policy(`bar_is_logger',`
  test_logger_domain_privs(bar_t)
')

Assigning attributes is not possible through a tunable_policy which is why this approach is preferred.

SELinux Roles

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.

SELinux Packages

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.