Project Overview

The SELinux Reference Policy project (refpolicy) is creating a complete SELinux

policy as an alternative to the existing strict and targeted policies available

from http://selinux.sf.net. Once complete,

this policy will be able to be used as the system policy for a variety of

systems and used as the basis for creating other policies. Refpolicy is based on

the current strict and targeted policies, but aims to accomplish many additional

goals.

Refpolicy is under active development, with support and full time development

staff from Tresys Technology. The

current release is available from the download

page.  The status page has more details on

what is included in the current release.

The project is always looking for policy developers interested in contributing.

See the getting started guide for

more information on writing Refpolicy modules.

Project Goals

Security is the reason for existence for SELinux policies and must,

therefore, always be the first priority. The common view of security as a binary

state (secure or not secure) is not a sufficient goal for developing an SELinux

policy. In reality, different systems have different requirements and purposes

and corresponding differences in the meaning of secure. What is a fundamental

security flaw on one system might be the acceptable, or even the primary

functionality, of another. The challenge for a system policies like the current

strict and targeted policy or refpolicy is to support as many of these differring

security goals as is practical. To accomplish this refpolicy will provide:

	
Strong Modularity: central to the design of the policy is

		strict modularity. Access to resources are abstracted, and

		implementation details are encapsulated in the module.

	
Security Goals: clearly stated security goals will for each

		component of the policy. This will allow policy developers to

		determine if a given component meets their security needs.

	
Documentation: the difficulty and complexity of creating

		SELinux policies has become the number one barrier to the

		adoption of SELinux. It also potentially reduces the security

		of the policies: a policy that is too complex to easily

		understand is difficult to make secure. Refpolicy will make

		aggressive improvements in this area by including documentation

		for modules and their interfaces as a critical part of the

		infrastructure. See the documentation

		page for more information.

	
Development Tool Support: In addition to documentation,

		Refpolicy aims to make improvements in this area, making

		policies easier to develop, understand, analyze, and verify by adding

		interface call backtraces which can be used for debugging and

		graphical development tools.

	
Forward Looking: Refpolicy aims to support a variety of

		policy configurations and formats, including standard source

		policies, MLS policies, and loadable policy modules

		all from the same source tree. This is done through the addition

		of infrastructure for automatically handling the differences

		between source and loadable module based policies and the

		additional MLS fields to all policy statements that include

		contexts.

	
Configurability: configuration tools that allow the

		policy developer to make important security decisions including

		defining roles, configuring networking, and trading legacy

		compatibility for increased security. 

	
Flexible Base Policy: a base policy that protects the basic

		operating system and serves as a foundation to the rest of the

		policy. This base policy should be able to support a variety of

		application policies with differing security goals.

	
Application Policy Variations: application policy variations

		that make different security tradeoffs. For example, two Apache

		policies might be created, one that is for serving read-only

		static content that is severely restricted, and another that is

		appropriate for dynamic content.

	
Multi-Level Security: MLS will be supported out-of-the-box

		without requiring destructive changes to the policy. It will be

		possible to compile and MLS and non-MLS policy from the same

		policy files by switching a configuration option.