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 first release is available from the download page. This release is far from complete and is not usable as a drop in replacement for the existing policies. It is for interested policy developers and community members to examine and comment upon. The status page has more details on what is included in the current release. This project is just getting started and we are looking for policy developers interested in contributing.

Project Goals

Security

Security is the reason for existence for SELinux policies and must, therefore, always be the first priority. The security of operating systems and applications is often presented as a binary state: software is either secure or not secure. In reality, that view of security is inadequate. 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 or targeted policy and refpolicy is to support all of these differring security goals. To accomplish this refpolicy will provide:

• 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.
• 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.
• Configuration Tools: configuration tools that allow the policy developer to make important security decisions including defining roles, configuring networking, and trading legacy compatibility for increased security.
• 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.

Usability and Documentation

• Security: refpolicy has a mandate to develop security goals that are clear and rigoursly applied
• Usability: refpolicy will be easier to understand and use.
• Documentation: refpolicy has a structure that makes it possible to create in-depth documentation.
• Flexibility: refpolicy will support source, loadable, and MLS modules with simple configuration.

Roadmap