Secure Operating Systems

richnessokahumpkaServers

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

82 views


Secure Operating Systems

Lesson
D
:
SELinux

Where are we?


We just studied Linux security features… but
it appears we can go one better:
SELinux


SELinux
: History


Developed by the NSA, and open sourced in
2000


Basically, it’s not as exciting as it sounds


leverages LSM to provide for MAC

Linux Security Modules


If you were designing changes to support
security to the Linux kernel what design
paradigm would you pick and why?


Pluggable modules


double edged


Great for adding flexible security


Horrible, as they allow rootkits easy access to the
kernel

Components


The
SELinux

Reference Monitor


Trusted services for administration


General trusted services


The Reference Monitor


Doesn’t just apply to users and files


can
include sockets etc.


Uses LSM hooks to determine authorization


Example: file access


Kernel decides based on
inode

(ultimately)


Subject, object, operation model (who, where,
what, kind of…)

Context/relationship

User

Role 1

Context A

Context B

Context C

Role 2

Context D

Context E

Type Enforcement


The combination of TE and MLS is powerful in
SELinux



Rule: allow <subject> <object>: <
obj

class> <ops>


Rule:
allow
user_t

bin_t

: file {execute
getattr
};


Means: a process with a domain of
user_t

can execute
and get the attributes of a file with a type of
bin_t


SELinux

is default deny environment


TE is VERY powerful… perhaps we should do a class
on it?

Labels


All of the above relies on labels (like
user_t
)


Can define for files based on location


Labels inherited from parents (i.e. file gets
label from parent directory)


Can create rules that
o
verride default labeling
using
type_transition

rules

SELinux



Transition state


Can change label at execution time


Better that
setuid
:


Transition to a specified label not a whole user
(e.g.
setuid

root)


Limits who/what can execute our transition
(anyone can call a
setuid

root program, not true
for
SELinux
)


Reminiscent of
Multics

(hello
Hilary) ring
bracketing but much finer grained

Administration


Yow… as you can imagine, this can be gnarly


Can enforce least privilege for services


very
handy!


Typically, you don’t do this yourself; there’s
plenty of books on this topic!


What happens to “root” under
SELinux
?

SELinux

Trusted Programs


Some applications


like X server


need to
be customized to work in
SELinux

properly.


Of course, there’s a bunch of trusted programs
too (like
passwd

or
init
)

Verification?


Complete Mediation?


Yes! Designed to mediate all access according to
TE etc. Should mitigate TOCTOU


Tamperproof?


Modules run in Ring 0 (huh… didn’t we talk
about this?)


Verifiable?


Kind of

Things to Do


Take a look at “Securing
Android
-
Powered
Mobile Devices Using
SELinux



Easy read, lots of good information!

Questions & Comments


What do you want to know?