Skip to content
This repository has been archived by the owner on Jul 2, 2018. It is now read-only.

Home

Jump to bottom
Chris PeBenito edited this page Jun 23, 2018 · 8 revisions

SELinux Reference Policy has moved to SELinuxProject: https://github.com/SELinuxProject/refpolicy

#SELinux Reference Policy Project Overview

The SELinux Reference Policy project (refpolicy) is a complete SELinux policy that can be used as the system policy for a variety of systems and used as the basis for creating other policies. Reference Policy was originally based on the NSA example policy, but aims to accomplish many additional goals.

Reference Policy is under active development, with support and development staff from Tresys Technology. The current release is available from the DownloadRelease 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 GettingStarted guide for more information on writing Reference Policy modules.

For an in-depth discussion of Reference Policy concepts, see the paper published at the 2006 SELinux Symposium.

#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 acceptable, or even the primary functionality, of another. The challenge for a system policy is to support as many of these differing security goals as is practical. To accomplish this Reference Policy will provide:

  • Strong Modularity: central to the design of the policy is strict modularity. Accesses to resources are abstracted, and implementation details are encapsulated in the module.

  • Security Goals: clearly stated security goals will be given 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. Reference Policy 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, Reference Policy 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: Reference Policy 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 is supported out-of-the-box without requiring destructive changes to the policy. It is possible to compile an MLS and non-MLS policy from the same policy files by switching a configuration option.

Clone this wiki locally