Chapter 9

solidseniorServers

Dec 9, 2013 (3 years and 11 months ago)

159 views

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