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 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? Tamperproof? Verifiable? 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?