SELinux is a mandatory access control system which enables a more fine-grained mechanism where the security administrator defines what a user can do. Unlike the standard discretionary access control in place for Linux (where the end user can still decide for himself how his resources are accessed by others) a mandatory access control system is fully governed through a security policy. With SELinux, enforcement of the access controls is done by the Linux kernel, governed through a security policy that is loaded at start of the system.
Linux has a well-known discretionary access control system, based on the permission mask set on resources and the ownership of the resource versus the run-time privileges of a process. Some additional security features are available as well, such as capabilities and extended ACLs, which allow administrators to fine-tune the secure state of their system. But even all those features still prove to be discretionary in their model.
A discretionary model means that the owner of a resource can still decide how the resource is shared on the system. A directory can be made world-writable by its owner, and from that point onwards all processes on the system can write to the directory. With a mandatory access control system, the access to resources is governed through a mandatory system that cannot be worked around from. With SELinux, this is the SELinux security subsystem running in the Linux kernel.
A quick introduction to SELinux helps to have a high-level idea behind the SELinux security subsystem. It covers the difference between discretionary and mandatory access control, the labeled approach that SELinux takes and how it is integrated in the Linux operating system.
For more in-depth information, please refer to the following resources.
|Type enforcement||Controlling accesses is done in most cases through a type-enforcement based approach|
|Role-based access control||Ensuring a least privilege approach on a Linux system using SELinux' RBAC model|
|User-based access control||Ensuring segregation of users, even when they run using the same domains and accessing the same types|
|Information flow control||Limiting information flow based on security clearance and sensitivities|
|Unconfined domains||When SELinux protections are not needed in all cases, unconfined domains can be used.|
|Installation||The main resource for installing and enabling SELinux on a Gentoo system|
|Users and logins||Mapping Linux users (logins) to SELinux users|
|Managing labels||Setting and configuring file (and other resource) labels|
|Policy||The SELinux policy defines the acceptable behavior on a system; it can be rebuilt by administrators, loaded and unloaded (through its modular design) and tweaked by adding more policy rules|
|Logging||SELinux usually logs denials in the audit log (or system log if no auditing is enabled)|
|Booleans||Enable or disable additional policy controls through SELinux booleans|
|States||SELinux can be enabled or disabled, and running in enforcing, partial permissive or full permissive mode|
|Policy development||Updating SELinux policy to suit your needs, and send patches to Gentoo or even upstream projects|
|Policy store||The policy store contains the SELinux policy binaries; multiple stores can be defined on a system|
|Networking support||SELinux supports port labeling, but also packet-based access controls through SECMARK and peer-to-peer labeling support|
|FAQ||Frequently Asked Questions on SELinux and SELinux integration in Gentoo|
|SELinux policy language||Supported SELinux language constructs|
|Policy module specific information||More in-depth information about particular SELinux policy modules|
For engineers and developers, we provide the following resources:
|Linux Security Modules||The integration of SELinux in the Linux kernel is done through the LSM subsystem|
|Reference policy||All Linux distributions base their SELinux policies on the reference policy|
|SELinux userspace project||The software that engineers and administrators use to work with SELinux|
|Gentoo Linux integration|
|Gentoo SELinux project||Project site of the Gentoo SELinux project|
|Profiles||Enabling SELinux support in default Gentoo profiles|
|Policy packages||Information on how the Gentoo packages push out SELinux policies to a system|
We also provide the following resources to gradually learn about SELinux.
|SELinux tutorials||More than a dozen small tutorials that introduce you to SELinux and its Gentoo integration|
May 10, 2015: Introducing 2.4 userspace
The SELinux userspace 2.4 release has now hit stable in the Portage tree. All necessary migrations related to the release are automatically done as part of the sys-libs/libsemanage package, so no manual migration effort is needed anymore.
October 30, 2014: Migrating policy module store
After upgrading to the 2.4 SELinux userspace, you might need to migrate the policy module store as follows (if the automated migration in the ebuild failed):
Without it, updating SELinux configurations through the userspace might give a warning about not having a managed store:
setsebool -P allow_ptrace on
Cannot set persistent booleans without managed policy.
However, not migrating the store does not influence the operational working of the system (so if you forget to do it, you will not be locked out).
SELinux in Gentoo
Problems with SELinux in Gentoo?
- Report a bug in bugzilla
Want some help?
- Try the gentoo-hardened mailinglist
- Call out to us through IRC on freenode's
- The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments explains the need for mandatory access controls
- The Flask Security Architecture: System Support for Diverse Security Policies explains the security architecture of Flask, the architecture used by SELinux.