Chapter 1.

SELinux Architectural Overview

This chapter is an overview of the SELinux architecture, building upon what was discussed in Section

1 What Is SELinux?. The technical information you learn here helps you accomplish your goals in an

SELinux environment. This chapter discusses the interaction of SELinux policy, the kernel, and the

rest of the OS. Chapter 2 SELinux Policy Overview provides a more detailed look into the policy itself.

1.1. Flask Security Architecture and SELinux

For a history of SELinux and the Flask architecture, read Appendix A Brief Background and History

of SELinux.

Flask was developed to work through some of the inherent problems with a MAC architecture. Tradi 

tional MAC is closely integrated with the multi level security (MLS) model. Access decisions in MLS

are based on clearances for subjects and classifications for objects, with the objective of no read up,

no write down . This provides a very static lattice that allows the system to decide by a subject's se 

curity clearance level which objects can be read and written to. The focus of the MLS architecture is

entirely on maintaining confidentiality.

The inflexible aspect of this kind of MAC is the focus on confidentiality. The MLS system does

not care about integrity of data, least privilege, or separating processes and objects by their duty,

and has no mechanisms for controlling these security needs. MLS is a mechanism for maintaining

confidentiality of files on the system, by making sure that unauthorized users cannot read from or

write to them.

Flask solves the inflexibility of MLS based MAC by separating the policy enforcement from the

policy logic, which is also known as the security server. In traditional Flask, the security server holds

the security policy logic, handling the interpretation of security contexts. Security contexts or labels

are the set of security attributes associated with a process or an object. Such security labels have the

format of

user : role : type

, for example,

system_u:object_r:httpd_exec_t

. The

SELinux user

system_u

is a standard identity used for daemons. The role

object_r

is the role for

system objects such as files and devices. The type

httpd_exec_t

is the type applied to the

httpd

executable

/usr/sbin/httpd

. The label elements user, role, and type are explained in Section 2.10

SELinux Users and Roles and Section 2.7 TE Rules   Types.

Prior to full integration with the Linux kernel, security contexts were maintained separately in a file

as a set of security identifiers or SIDs. Part of the change when moving to the Linux 2.6.x kernel

is the usage of extended attributes (EAs) in the file system. SIDs are not entirely retired, but they

are no longer exported to userspace from the kernel. For example, the kernel has some initial SIDs

used by

init

during bootstrapping before the policy is loaded. In addition,

libselinux

provides

a userspace SID abstraction for applications that enforce policy, such as

dbus daemon

and

nscd

.

Otherwise, users and other programs only interact with security contexts. To minimize confusion,

from here forward in this guide, the term security context is used to include the SID.

The security server need only do a look up with a pair of contexts on a matrix of type labeled subjects

and objects, and the result is put in the access vector cache (AVC) for retrieval on subsequent matching

requests.

By adding in a generalized form of TE that is separated into its own security subsystem, Flask can be

flexible in labeling for transition and access decisions. Instead of being tied to a rigidly defined lattice

of relationships, Flask can define other labels based on user identity (UID), role attributes, domain or

type attributes, MLS levels, and so forth.

Similarly, access decision computations can be made using multiple methods in the same decision.

These methods could be lattice models, static matrix lookups, historical decisions, environmental