Chapter 9


Dec 9, 2013 (4 years and 7 months ago)


Chapter 9

Building a Secure Operating System for Linux

Chapter Overview

Linux Security Modules




Reference Monitor

Protection State

Labeling State

Transition State


Trusted Programs

Security Evaluation

Linux Security Modules

Reference Monitor System for the Linux kernel.

Consists of two parts:

Reference Monitor Interface

Reference Monitor Module (LSM)

Several LSM's have been

Have covered AppArmor

Will try to cover SELinux

LSM History

Lots of early security work on Linux:

Argus PitBull


Subdomain (AppArmor)



DTE for Linux

Medusa DS9

Open Wall

HP's initiative

Flask (SELinux)

LSM History (II)

Obviously, (2001) a reference monitor was
necessary for Linux; everybody was reinventing
the wheel! But:

Linus Torvalds was not a security expert, could
not decide on an approach

There was no real agreement as to which was
the “best” approach.

Result was a design basde on kernel modules
with a single interface for all the necessary

LSM framework

LSM Requirements:

The reference monitor must be truly
generic, so that switching to a different
security model was simply a matter of
loading a different kernel module.

The interfaces must be “conceptually
simple, minimally invasive, and efficient.”

Must support the POSIX.1e capabilities
mechanism as an “optional security

Design of the reference monitor

Formed union of all projects to date.

Restricted number of authorization queries to prevent
redundant authorizations.

Manual design, source code analysis tools were used to
verify completeness and consistency, finding six bugs.

Most of the interface had negligible performance impact
except for the CIPSO implementation. Network security is
now supported inoe of two ways:

Labeled IPSec

New implementation of CIPSO called Netlabel

LSM History, final details

LSM framework was officially added to
Linux kernel in version 2.6.

SELinux and POSIX capabilities were
included with the release of LSM

Novell bought the company that supported
AppArmor, so AppArmor is also available.

LSM Implementation

LSM Framework implemetation has three

Reference monitor interface definition

Reference monitor interface placement

Reference monitor implementation

LSM Reference Monitor definition

Specifies the way the kernel can invoke the LSM
reference monitor.

The description is in the file
include/linux/security.h in the kernel sources. It
defines a structure security_operations with all
the LSM function pointers. They are called LSM

150 hoks for authorizations, plus other hooks for
labels, label transitions. And label maintenance.

LSM Reference Monitor placement

Where to place the hook?

At the entrance to the system call?

What about TOCTTOU attacks?

What about the “open” system call?

The hooks were placed using in
function declarations.

LSM Hook Architecture

LSM Reference Monitor Implementation

Each LSM reference monitor is different.

However, most security enhanced versions
of Linux use the same hooks.

Exception is RSBAC

Enhanced Linux

SELinux Reference Monitor

Two distinct processing steps.:

Convert input values from the LSM hooks
into one or more authorization queries.

Check against SELinux protection system.

SELinux Protection State

SELinux Contexts

SELinux Contexts

Previous diagram gave idea of user labels;; each
context has permissions assigned to it.

There is also an MLS policy, but, though it allows
read down, it only allows write level.

Both type labels and MLS labels are checked.

20 different object data types, and many operations,
including read, write, execute, create, ioctl, fcntl,
extended attributes, ..

Over 1000 state labels.

Very complex administration!

SELinux Labeling State

Files/objects are labeled (by default) based
on their location in the file system, but file
contexts can be used to override the

Labels are inherited. For files, the label of
a file is inherited from the label of its parent
directed, some processes may have
permission to relabel them.

SELinux Transition State

Rather than SUID programs, a label
transition is only allowed at execution; the
transition only gives limited privileges; also,
not all programs can run a transitioning

Instead of gatekeepers, SELinux relies
onprogrammers to keep program safe.

SELinux Administration

Different kinds of policies:



Policy development:

Strict policy

Targeted (like AppArmor)

Reference Policy

SELinux Trusted Programs

SELinux Security Evaluation