1 / 15

Secure Operating Systems

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

betty
Download Presentation

Secure Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure Operating Systems Lesson D: SELinux

  2. Where are we? • We just studied Linux security features… but it appears we can go one better: SELinux

  3. 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

  4. 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

  5. Components • The SELinux Reference Monitor • Trusted services for administration • General trusted services

  6. 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…)

  7. Context/relationship

  8. 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?

  9. 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

  10. 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

  11. 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?

  12. 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)

  13. 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

  14. Things to Do • Take a look at “Securing Android-Powered Mobile Devices Using SELinux” • Easy read, lots of good information!

  15. Questions & Comments • What do you want to know?

More Related