|Description||This project manages SELinux support in Gentoo. This includes providing kernels with SELinux support, providing patches to userland utilities, writing strong Gentoo-specific default profiles, and maintaining a good default set of policies.|
No lead election date set
(and inherited member(s))
|Parent Project||Gentoo Hardened|
Security-Enhanced Linux (SELinux) is a Mandatory Access Control system using type enforcement and role-based access control. It is integrated within Linux as a Linux Security Module (LSM) implementation. In addition to the kernel portion, SELinux consists of a library (libselinux) and userland utilities for compiling policy (checkpolicy), and loading policy (policycoreutils), in addition to other user programs.
One common misconception is that SELinux is a complete security solution. It is not. SELinux only provides access control on system objects. It can work well with other Hardened projects, such as PaX, for a more complete solution.
Our goal is to make SELinux (with Gentoo Hardened) available to more users. As a result, we:
- Develop, improve and maintain the proper documentation and learning material for end users to master SELinux.
- Maintain a stable yet progressive set of userland tools that are needed to interoperate with SELinux on a Linux system (such as the core utilities, libselinux and more).
- Focus on the integration of SELinux and SELinux-awareness within the Gentoo distribution, offering the necessary feedback on Portage and other utilities.
- Develop, improve and maintain a good and secure default policy, based on the reference policy, so that end users have no difficulties working with and enhancing SELinux within their environment.
Special thanks to
The following people are or have been actively contributing to the project:
|Chris Richards||gizmo||Policy development, support|
|Christopher PeBenito||pebenito||Previous SELinux subproject lead, policy development, packaging and support|
Resources offered by the SELinux project include:
|SELinux documentation||The main user documentation portal on the wiki|
|Reporting SELinux (policy) bugs||A guide on writing helpful SELinux related bug reports|
|SELinux policy constraints||A short introduction to the constraints that are active in the SELinux policy|
|Development oriented documentation|
|SELinux policy package development||How to create policy ebuilds|
|SELinux development policy||Policy on developing SELinux policies within Gentoo, including the principles and security models used in Gentoo Hardened|
|Coding style||Coding style for SELinux policies|
I want to participate
To participate in the SELinux project first join the mailing list at firstname.lastname@example.org. Then ask if there are plans to support something that you are interested in, propose a new sub-project that you are interested in or choose one of the planned sub-projects to work on. You may talk to the developers and users in the IRC channel #gentoo-hardened on Freenode for more information or just to chat about the project or any sub-projects. If you don't have the ability to actively help by contributing work we will always need testers to use and audit the SELinux policies. All development, testing, feedback, and productive comments will be greatly appreciated.
The critical component of a SELinux system is having a strong policy. The team does its best to support as many daemons as possible. However, we cannot create policies for daemons with which we are unfamiliar. But we are happy to receive policy submissions for consideration. There are a few requirements:
- Make comments (in the policy and/or bug), so we can understand changes from the Reference Policy example policy.
- The policy should cover common installations. Please do not submit policies for odd or nonstandard daemon configurations.
- We need to know if the policy is dependent on another policy (for example rpcd is dependent on portmap) other than base-policy.
The policy should be submitted on Bugzilla. Please attach the .te and .fc files separately to the bug, not as a tarball. The bug should be Cc'ed to email@example.com and will be properly reassigned by the team.