Chapter 1. SELinux Architectural Overview

3

3. The policy server first checks the AVC, and returns a decision to the enforcement server.

If the AVC does not have a policy decision cached, it turns to the security server, which uses the

binary policy that is loaded into the kernel during initialization. The AVC caches the decision, and

returns the decision to the enforcement server, that is, the kernel.

4. If the policy permits the subject to perform the desired operation on the object, the operation is

allowed to proceed.

5. If the policy does not permit the subject to perform the desired operation, the action is denied,

and one or more

avc: denied

messages are logged to

$AUDIT_LOG

, which is typically

/var/log/messages

in Red Hat Enterprise Linux.

With the security server handling the policy decision making, the enforcement server handles the rest

of the tasks. In this role, you can think of the enforcement code as being an object manager. Object

management includes labeling objects with a security context, managing object labels in memory, and

managing client and server labeling.

1.2. SELinux, an Implementation of Flask

SELinux has been through several iterations as part of the process of being incorporated into the Linux

kernel. During this time, the overall architecture has remained the same, but many of the programmatic

details have changed. Some of the reasons for change were: requirements for upstream acceptance;

changes in LSM as part of being accepted into the kernel; and the switch to using xattrs.

As one example of the changes between kernel versions, originally security context was maintained

through a mapping from context to SID, and managed by the security server. In the 2.6.x Linux

kernel, the security context for a file is stored in the xattrs, allowing it to carry around its own SELinux

context.

As an implementation of the Flask architecture, SELinux also served as a reference implementation

of LSM. Originally LSM and SELinux were patches to the 2.4. x

series of kernels; SELinux was

never able to work as a loadable security module. Therefore, a big part of gaining upstream acceptance

into the mainline Linux kernel required everything from fixing coding practices to changing how

SELinux interacted with the kernel.

Part of the SELinux development team was also instrumental in designing, building, and integrating

LSM into the kernel. SELinux integration into the kernel was the motivation to start the LSM project.

SELinux was an early proof of the ability of LSM to allow security enhancements to be connected

into, instead of strapped onto, the Linux kernel. Originally, SELinux was a loadable module, but it

became statically compiled into the 2.6.x kernel. It is still an LSM module, using the LSM hooks in

the kernel to control and label. Because of the abstraction layer provided by both the LSM and Flask

frameworks, SELinux is highly configurable and modifiable.

Flask is flexible enough to work in many different environments, and Linux is a natural fit for the

Flask model. Access to the kernel source and a willing, community driven development process allow

for the best modification to fully support Flask's objectives. The wide range of platforms Linux runs

on means SELinux is extensively tested. The consensus process of getting SELinux integrated into the

kernel has improved the code and practices. Now that it is integrated, it has a better chance of long 

term success than security enhancement models that are strapped on top of the operating system.

There are a few more differences in the specific way SELinux implements Flask in the Linux kernel,

compared to traditional Flask methodology and initial SELinux creation:

1. Under traditional TE, there is a distinction between types and domains. A type is the security

context for a file object, and a domain is the security context for a process. In the SELinux im 

plementation, there is no real distinction programmatically. In SELinux, domains are processes

that have the attribute

process

, so the term domain is used in the traditional way. Similarly,

the term type is mostly applied to object types, but it can mean both domains and types.