2

Chapter 1. SELinux Architectural Overview

decisions, or policy logic obtained in real time. These computations are all handled by the policy

engine and cached, leaving the policy enforcement code available to handle requests.

One other Flask flexibility is that any of these subsystems can be swapped out for a new or different

system, and none of the other systems are even aware of the change. The abstraction between policy

enforcement and policy decision making is what makes this possible. This flexibility gives Red Hat

Enterprise Linux developers the control they need to make the best architecture decisions without

being tied to a particular subsystem.

Subject

(application,

process)

Object

(device)

context(a)

context(b)

Object

(file)

Subject

(user)

context(a,b)

Policy

enforcement

server

Security

AVC

server

yes

no

Binary policy

Subject

Object

Subject

Object

(application)

(matrix)

(application)

(process)

(process)

Object (file)

Object (file)

Subject (user)

Subject (user)

avc:  denied

Figure 1 1. Flask Architecture

Figure 1 1 describes the Flask architecture, showing the process of an operation. In this operation,

standard DAC has occurred, which means the subject already has gained access to the object via

regular Linux file permissions based on the UID

1

. The operation can be anything: reading from or

writing to a file/device, transitioning a process from one type to another type, opening a socket for an

operation, delivering a signal call, and so forth.

1. A subject, which is a process, attempts to perform an operation on an object, such as a file, device,

process, or socket.

2. The policy enforcement server gathers the security context from the subject and object, and sends

the pair of labels to the security server, which is responsible for policy decision making.

1. This type of access control is also called identify based access control or IBAC.