From SELinux Wiki
|Revision as of 13:49, 16 May 2010 (edit)
RichardHaines (Talk | contribs)
(New page: = SELinux Overview = == Introduction == SELinux is the primary Mandatory Access Control (MAC) mechanism built into a number of GNU / Linux distributions. SELinux originally started as the ...)
← Previous diff
|Revision as of 20:48, 13 September 2010 (edit) (undo)
Jaxelson (Talk | contribs)
Next diff →
|Line 45:||Line 45:|
Revision as of 20:48, 13 September 2010
SELinux is the primary Mandatory Access Control (MAC) mechanism built into a number of GNU / Linux distributions. SELinux originally started as the Flux Advanced Security Kernel (FLASK) development by the Utah university Flux team and the US Department of Defence. The development was enhanced by the NSA and released as open source software. The history of SELinux can be found at the Flux and NSA websites.
Core SELinux Components
The High Level Core SELinux Components diagram shows a high level view of the SELinux core components that manage enforcement of the policy and comprise of the following:
- A subject that must be present to cause an action to be taken by an object (such as read a file as information only flows when a subject is involved).
- An Object Manager that knows the actions required of the particular resource (such as a file) and can enforce those actions (i.e. allow it to write to a file if permitted by the policy).
- A Security Server that makes decisions regarding the subjects rights to perform the requested action on the object, based on the security policy rules.
- A Security Policy that describes the rules using the SELinux policy language.
- An Access Vector Cache (AVC) that improves system performance by caching security server decisions.
The High Level SELinux Architecture diagram shows a more complex view of kernel and userspace with a number of supporting services which are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore using the diagram as the reference and starting from the bottom:
- In the current implementation of SELinux, the security server is embedded in the kernel with the policy being loaded from userspace via a series of functions contained in a library (libselinux).
- However the object managers (OM) and access vector cache (AVC) can reside in:
- kernel space - These object manages are for the kernel services such as files, directory, socket, IPC etc. and are provided by hooks into the SELinux sub-system via the Linux Security Module (LSM) framework (shown as LSM Hooks in the diagram) that is discussed in the Linux Security Module(LSM) section. The SELinux kernel AVC service is used to cache their requests and the security servers response.
- userspace - These object managers are provided with the application / service that requires support for MAC and are known as "SELinux-aware" applications or services. Examples of these are: X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL database, Name Service Cache Daemon (nscd), and the GNU / Linux passwd command. Generally, these OMs use the AVC services built into the SELinux library (libselinux), however they could if required supply their own AVC or not use an AVC at all.
- The loadable policy (right hand side of the diagram) and its supporting configuration files are contained in the /etc/selinux directory. This directory contains the main SELinux configuration file (/etc/selinux/config) that names the policy to be loaded and the initial status of SELinux at boot time (enforcing the policy or not). The area also holds all policies that can be activated in their respective directories /etc/selinux/<policy_name> (e.g. /etc/selinux/targeted would hold the "targeted" F-12 policy and all its configuration files). All know configuration files for F-12 SELinux are shown in the SELinux Configuration Files section.
- SELinux supports a "modular policy", this means that a policy does not have to be one large policy, but can be built from modules. A modular policy consists of a base policy that contains the mandatory information (such as object classes, permissions etc.), and zero or more policy modules that generally support a particular application or service. These modules are compiled, linked, and held in a "policy store" where they can be built into a binary format that is then loaded into the security server. The types of policy and their construction are covered in the Types of SELinux Policy section.
- To be able to build the policy in the first place, policy source is required (top left hand side of the disgram). This can be supplied in two basic ways:
- as source code written using the SELinux Policy Language. This is how the simple policies have been written to support the examples in this Notebook, however it is not recommended for real-world policy development.
- using the Reference Policy that uses high level macros to define policy rules as well as the policy language. This is the standard way policies are now built for SELinux distributions such as F-12.
- To be able to compile and link the source code and load it into the security server requires a number of tools (top of the diagram).
- To enable system administrators to manage the policy, the SELinux environment and label file systems also requires tools and modified GNU / Linux commands.
- To ensure security events are logged, GNU / Linux has an audit service that captures policy violations. The Audit Logs section describes the format of these AVC security events.
- SELinux supports network services that are described in the SELinux Networking Support section.
The Linux Security Module and SELinux section goes into greater detail of the LSM / SELinux modules with a walk-through of a fork and exec process.
- ↑ There is a project developing a Policy Management Server (PMS) that will utilise a user-space security server, however it is beyond the scope of this Notebook.
- ↑ Generally this means that they use the services provided by the libselinux library as a minimum.
- ↑ When SELinux is enabled the policy can be running in "permissive mode", where all accesses are allowed and logged in the audit log, even if they are not permitted by the policy (useful for debugging policy). The policy can also be run in "enforcing mode", where any access that is not defined in the policy is deigned and an entry placed in the audit log.