Chapter 9
Building a Secure Operating System for Linux
Chapter Overview
•
•
Linux Security Modules
–
History
–
Implementation
SeLinux
–
Reference Monitor
–
Protection State
–
Labeling State
–
Transition State
–
Administration
–
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
implemented.
• Have covered AppArmor
• Will try to cover SELinux
LSM History
•
Lots of early security work on Linux:
–
Argus PitBull
–
LIDS
–
Subdomain (AppArmor)
–
RSBAC
–
GRSecurity
–
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
modules.
•
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
module”.
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
parts:
–
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
hooks.
•
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-line
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
Security-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
defaults.
•
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
prtogram.
•
Instead of gatekeepers, SELinux relies
onprogrammers to keep program safe.
SELinux Administration
•
•
Different kinds of policies:
–
Monolithic
–
Modular
Policy development:
–
Strict policy
–
Targeted (like AppArmor)
–
Reference Policy
SELinux Trusted Programs
SELinux Security Evaluation