150 likes | 290 Vues
In this lesson, we explore the fundamentals of SELinux (Security-Enhanced Linux), developed by the NSA and open-sourced in 2000. We discuss its integration with Linux security features and the role of Linux Security Modules (LSM). You will learn about the SELinux Reference Monitor, the power of Type Enforcement (TE) and Multi-Level Security (MLS), and how SELinux enforces security through context labels and rules. Furthermore, we touch on the importance of trusted programs and their role within SELinux’s framework for a more secure operating environment.
E N D
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…)
Type Enforcement • The combination of TE and MLS is powerful in SELinux… • Rule: allow <subject> <object>: <obj class> <ops> • Rule: allow user_tbin_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?