Upload
betty
View
39
Download
0
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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?