Reference Policy for Security Enhanced Linux

Christopher J. PeBenito, Frank Mayer, Karl MacMillan

Tresys Technology

Abstract

The Reference Policy project is an effort to restructure the NSA example policy for SELinux, which has evolved
through many years of community involvement and is the basis for nearly all sample SELinux Policy in use today.
The Reference Policy is rigorously structured using modularity, layering, encapsulation, and abstraction, making it
simpler to maintain, modify, and use. The goal of this restructuring is to allow greater adaptation and adoption of
SELinux while maintaining the knowledge gained through the years of policy evolution, while increasing our ability
to validate the security properties of a given SELinux policy.

1. Motivations • Functionality: Provide better software engi-

neering discipline to the structure of policy
When expressing security goals for an application in an source files such that maintaining the policy is
Security Enhanced Linux (SELinux) policy, it is impor- easier, adding application policy modules is
tant to have a strong foundation to build upon. The simpler, and building high-level tools such as
problem with the sample policy that evolved from the graphical policy editors is feasible.
original NSA policy [1] is that the policy is difficult to
understand, develop, and maintain unless you are inti- 2.1. Security Goals
mately familiar with the SELinux enforcement mecha-
nism and the policy language. In the example policy, Security is the primary reason for using the SELinux
source files have loose structure and policy modules are enhancements to Linux, and as such, it must also be the
closely coupled. A policy writer must have detailed first priority for the Reference Policy. Commonly,
knowledge of most if not the entire policy in order to when looking at the security of a system, it as viewed in
use it as a basis for new application policy modules. a true or false state; the system is secure or it is not. In
Creating third-party modules is difficult, requiring de- reality, this is not sufficient, as different systems have
tailed understanding of type, role, user, attributes, etc. different purposes, and correspondingly, a different
definitions throughout the entire policy. While most meaning of what is secure. One of the great features of
policies in use today, e.g., [2] [3], are based on the SELinux, is its use of type enforcement as its manda-
original NSA sample policy, the single largest com- tory access control mechanism, which allows policy
plaint about SELinux is that writing policy is too diffi- writers to specify the security properties they need.
cult and complex.
Reference Policy has four primary security goals,
Tresys started the Reference Policy [4] project to re- which are generally goals of any SELinux policy:
factor the community knowledge gained through evolu-
tion of the NSA example policy, into a form that exhib- • Self-protection: for the system itself, the
its many of the strengths and features of modern soft- SELinux policy, and for each application (to
ware engineering, thereby making the policy more be protect itself from other applications);
maintainable, verifiable, and useable.
• Assurance: confidence in the correctness and
2. Reference Policy Goals completeness of all SELinux policy compo-
nents, throughout the policy development life-
The Reference Policy project has two primary goals: cycle, including extensive use of least privi-
lege and limitation of error propagation [5], as
• Security: Provide a better foundation for en- well as increased understandability;
suring that security goals for SELinux systems
and applications are achieved and verifiable; • Secure extensibility: allowing specific applica-
and tions and services to be added to the SELinux
 policy while maintaining other security goals The Reference Policy introduces or formalizes several
and assurance; and new concepts in order to achieve our goals. It also uses
strong rules for policy module constructions that help
• Improved role separation: role to be defined ensure these concepts are enforced.
via least privilege and fine-grained role defini-
tions to improve a current weakness of 3.1 Design Concepts
SELinux policies (i.e., overly powerful admin
domains). We defined several design concepts borrowed from
modern software engineering to guide the Reference
In our results to date, we believe we have made signifi- Policy project.
cant progress in all of these security goals except the
last, improved role separation, which is in our future 3.1.1. Layering
plans.
Layering in Reference Policy is a fairly weak principle,
2.2. Functional Goals and is primarily used to help organize modules and ease
user understandability. The deciding factor for which
There are several issues facing SELinux policy devel- layer a module belongs is sometimes ambiguous. In
opment that Reference Policy aims to address includ- general, modules are grouped by function in the sys-
ing: tem. Lower layer modules are generally included in
most system policies, for example, to protect kernel
• Managed complexity: reduce the amount of resources, or startup or shutdown the system. Higher
details that a policy writer must manage, mak- layer modules tend to be more optional, and are in-
ing it simpler to create new policy modules cluded as needed, such as for user applications or net-
without requiring intimate knowledge of the work-facing services. The layers currently defined are
underlying policy implementation; kernel, system, administration, services, and application
layers.
• Loadable modules support: support both exist-
ing, so-called monolithic policies as well as 3.1.2. Modularity
policies compatible with the emerging load-
able policy modules infrastructure [6] to be Modules are the smallest components in Reference Pol-
built from the same policy source files; icy, grouping related policy statements for a particular
domain and its resources. Groupings are mainly based
• Better support for tools: structure the policy on the similarity of function. Each module includes the
such that sophisticated policy development policy resource (e.g., type, attributes) declarations, as-
and analysis tools can work with policy sociated policy rules, and object labeling requirements.
sources more easily; This form of a module forms the basis for encapsula-
tion and abstraction of the policy statements, which we
• Third-party support: enable third parties, such discuss further below. Each module generally corre-
as OEMs, to create policy modules using sta- sponds to RPMs in a Red Hat system, which is a practi-
ble, well defined interfaces; cal decision to ease system configuration.

• Improved comprehension: allow policy writers The existing example policy has evolved a form of
to more easily understand the policy by ag- modularity that helps manage complexity, but in gen-
gressively adding documentation, enabling eral still leaves modules tightly coupled. For the Refer-
them to make security relevant decisions; and ence Policy we are more strict in the organization and
definition of modules, enforcing several strong rules by
• Policy configurations: supports the strict and convention.
targeted policies, MLS, and the recently added
MCS configuration [7] as build options, with- Each module has three component source files: 1) a
out requiring destructive changes to the policy private module policy (.te), 2) a set of external inter-
or multiple policy source trees. faces (.if), and 3) a file labeling policy (.fc). The pri-
vate policy file contains the declarations and rules that
3. Concepts, Rules, and Conventions are local to the module. The external interface file pro-
vides abstract access to types and attributes that are
private to the module, for other modules’ use. These the types and rules for ssh domains and keys for each
interfaces are designed to be intuitive, reflecting access role. Support macros parallel many of the “core mac-
to some set of system capabilities. A policy developer ros” in the NSA example policy, providing common
should be able to use an interface, understanding its policy patterns. Examples include domain transitions
purpose, without having to understand how the purpose and object class permission sets. Support macros are
is implemented within the module. The file labeling essentially “helper functions” that are used solely to
policy files consists of file contexts statements, if any, help simplify the private, internal implementation of a
associated with the module. module (i.e., they are never interfaces).

3.1.3. Encapsulation and Abstraction 3.1.4. Module Interfaces

The encapsulation rules for a module ensures that all of The most fundamental change to the current structure is
the module’s implementation details are private to the the use of macros for gaining access to a type outside of
module itself. This allows changes to the module’s im- the module in which the type is defined. Interfaces pro-
plementation without affecting other policy modules, vide access to a module’s policy resources (i.e., to its
reducing the coupling of policy modules. privately declared types and attributes). All domains
needing a particular access will use the same interface;
The Reference Policy has several important policy writ- therefore, the policy rules required for the access will
ing rules which capture the important concepts of en- be consistent across all users of the interface. Thus
capsulation and abstraction. Perhaps the most impor- policy changes for access to a type require only a
tant rule is type and attribute identifiers are private to a change in one place, rather than requiring changes to all
module; thus, types and attributes may not be directly the modules that use the type as is common in the sam-
referenced by name outside of the module in which it is ple policy.
declared. This also means that there are no global
types or attributes. In the future it may make sense to add interface and
templates macro semantics to the base language. As
Abstraction is used to create higher-level concepts of macros, any time an interface is changed, all modules
access. This enables policy writers to make security that use this interface must be recompiled. With inter-
relevant decisions, rather than being impeded with un- faces in the language, modules will become decoupled
derstanding all of the implementation details. M4 mac- on the loadable module level, in addition to the source
ros are used to create the abstractions, though in gen- level.
eral we enforce strict conventions on the type of macros
allowed, unlike the current practice of allow any form For improved clarity, interfaces follow clear naming
of macro that M4 can support 1 . Each macro contains conventions. In particular, the module name, or abbre-
only one concept, and rules are not added for conven- viation, is prefixed to the interface name. This allows a
ience. policy writer to look a policy and easily see where all
of the interface calls are. In addition, consistent verbs
There are three types of macros supported by Reference are used to describe the access, such as read, write, and
Policy: interface, template, and support. Interface mac- delete.
ros are those that export access to a module’s internal
types and/or transform a type, e.g., making a caller’s Each interface contains two parts, the dependencies and
type a “domain.” Interfaces are one of the primary in- the access. The dependencies are contained in a
novations of Reference Policy, providing most of the gen_require() macro. This macro contains the state-
de-coupling of module implementations. Template ments that would be placed in a require block for load-
macros are a special form of interfaces that create able modules. It lists all of the types and attributes used
and/or manipulate derived types on behalf of the call- by the interface. If an object class for a user space ob-
ers. While the derived types are conceptually private to ject manager is used, such as DBUS or NSCD, the ob-
the caller, their implementation details are contained ject class and required permissions must also be listed.
wholly within the module that creates the template
macros. These macros are used , for example, to create 3.1.4. Module Template Interfaces
1
In the future, we may remove M4 all together in favor of a Template macros are the only macros that can declare
custom-made parser, primarily because M4 is too flexible and types and attributes as part of an interface, i.e., the so-
invites abuse of our modularity rules. called derived types. The module defining the template
macro is the only places where explicit access to/from specifies the categories a file has when using a MCS
the derived types can be defined. The only real differ- policy. This allows a change between a MLS and non-
ence between interface and template macros is that tem- MLS policy, for example, without modifying the pol-
plate macros use and/or create derived types on behalf icy.
of the caller. Both macros are “interfaces” to the defin-
ing module and can access the module’s private types. 5. Summary

4. Module Example The Reference Policy project has many goals, both se-
curity and functional goals, but the most important one
Below is an excerpt from the BIND DNS server, from is to make the policy simpler to understand and main-
the Reference Policy. tain. It uses layering, modularity, encapsulation, and
abstraction to structure the policy, in addition to exten-
4.2 bind.te sive documentation, to better meet these goals.

Example 1 shows the complete private policy for the Interfaces, the most fundamental change to the policy,
named domain. The policy_module() macro contains abstract the details creating higher-level concepts of
the name and version of this module, which are used in access for policy writers. Modules encapsulate all of
loadable policy modules. The next nine lines contain the implementation details for a particular subset of
the type declarations and transformation macro calls. policy since all types and attributes are only directly
The type for the domain and its entry point program are usable from a particular module, and there are no
declared and transformed using the global types or attributes. Finally, layers organize the
init_daemon_domain() macro, which is an interface modules into more meaningful groups.
from the init module. The remainder of the private
policy contains the rules for the BIND service. For 6. References
access to types not in this module, there are nine calls
to interfaces of other modules complete the policy, for [1] http://selinux.sourceforge.net and
example logging_send_syslog_msg() is an interface http://www.nsa.gov/selinux
from the logging module that allows bind to send mes-
sages to the system log daemon. [2] http://fedora.redhat.com/download

4.3. bind.if [3] http://hardened.gentoo.org/selinux

Interfaces are defined in the module .if file. In Example [4] http://serefpolicy.sourceforge.net
2, we see a use of the interface() macro to define access
to entry the named domain (i.e., a domain transition [5] Peter A. Loscocco, Stephen D. Smalley, Pat-
interface). The caller would provide the type it wants to rick A. Muckelbauer, and Ruth C. Taylor.
have the access to enter the named domain. “The Inevitability of Failure: The Flawed As-
sumption of Security in Modern Computing
In addition to the actual interfaces, the interfaces file Environments.” In Proceedings of the 21st Na-
has its inline documentation encapsulated in XML, as tional Information Systems Security Confer-
also shown in Example 2. This provides documenta- ence, pages 303-314, October 1998.
tion not only for policy writers to see when reading the
file, but the XML can also be extracted from the policy [6] Karl MacMillan. “Core Policy Management
and read by development and analysis tools. Infrastructure for SELinux.” 2005 SELinux
Symposium.
4.4. bind.fc
[7] James Morris. “A Brief Introduction to Multi-
The structure of a module’s file contexts file has not Category Security (MCS).”
been changed, as illustrated in Example 3. To facilitate http://www.livejournal.com/users/james_morri
the use of MLS and MCS policies, a gen_context() s/5583.html
macro has been added. The regular type enforcement
file context is specified as the first parameter. The sec-
ond parameter provides the level of the file when a
MLS policy is being used. An optional third parameter
 policy_module(bind,1.1.0)

type named_t;
type named_exec_t;
init_daemon_domain(named_t,named_exec_t)

type named_cache_t;
files_type(named_cache_t)

type named_conf_t;
files_type(named_conf_t)

type named_zone_t;
files_type(named_zone_t)

allow named_t named_cache_t:file manage_file_perms;

allow named_t named_conf_t:file r_file_perms;
allow named_t named_zone_t:file r_file_perms;

kernel_read_system_state(named_t)
kernel_read_network_state(named_t)

corenet_non_ipsec_sendrecv(named_t)
corenet_udp_sendrecv_all_if(named_t)
corenet_udp_sendrecv_all_nodes(named_t)
corenet_udp_sendrecv_all_ports(named_t)
corenet_udp_bind_all_nodes(named_t)
corenet_udp_bind_dns_port(named_t)

logging_send_syslog_msg(named_t)

Example 1. Excerpt of BIND private policy file (bind.te)

## <summary>Berkeley internet name domain (DNS) server.</summary>

########################################
## <summary>
## Execute bind in the named domain.
## </summary>
## <param name="domain">
## Domain allowed access.
## </param>
#
interface(`bind_domtrans',`
gen_require(`
type named_t, named_exec_t;
')

domain_auto_trans($1,named_exec_t,named_t)

allow $1 named_t:fd use;

allow named_t $1:fd use;
allow named_t $1:fifo_file rw_file_perms;
allow named_t $1:process sigchld;
')
Example 2. Excerpt of BIND interface file (bind.if)

/etc/rndc.* -- gen_context(system_u:object_r:named_conf_t,s0)

/usr/sbin/named -- gen_context(system_u:object_r:named_exec_t,s0)

/var/named(/.*)? gen_context(system_u:object_r:named_zone_t,s0)
/var/named/slaves(/.*)? gen_context(system_u:object_r:named_cache_t,s0)
/var/named/data(/.*)? gen_context(system_u:object_r:named_cache_t,s0)

Example 3. Excerpt of BIND file contexts file (bind.fc)