Secure Operating Systems

Secure Operating SystemsLesson 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 2Context 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 override 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?