Security Enhanced Linux

1. Architecture and Applications Tom Vogt <tom@lemuria.org> Security Enhanced Linux

2. History Prototypes • Developed by the NSA and the Secure Computing Corporation (SCC) • DTMach and DTOS prototype operating systems • Later Flask, together with University of Utah Linux • Flask integrated into Linux => SELinux

3. Overview What it is • TE: Type Enforcement • MAC: Mandatory Access Controls • RBAC: Role-Base Access Control • Transparent for most applications • Orthogonal to Unix permissions

4. Background Type Enforcement • Strong separation between OS and programs • and between different programs

5. Background Mandatory Access Control • Normal Unix: Discretionary Access Control (DAC) • DAC: Object owners (users) determine access rights • With MAC: Policy and object labels determine access rights. Policy determines who can set labels. • Access rights enforced by system (kernel)

6. Background Role-Based Access Control • Access rights defined by roles that users have • Roles follow the minimum-privileges rule • Users can switch between roles • Policy determines available roles per user

7. Overview How it's done • Kernel patch • A few user space patches • Central policy with management tools • File system labelled with Security Contexts (stored in ext2/3 xattr) • Processes labelled with Security Contexts

8. Basics Security Contexts root:sysadm_r:example_t • SELinux User ID • Current SELinux Role • Current Domain/Type

9. Basics Users, Roles and Domains • Users are authorized for one or more roles • Roles can be changed (newrole command) • Roles are authorized for domains

10. Basics An example: • The user example is authorized for the role sysadm_r • The sysadm_r may execute files of the httpd_exec_t type • Upon execution, httpd_exec_t enters the domain httpd_t • The Apache web server now runs in a dedicated domain

11. Transitions The policy • ...defines which transitions are allowed • defines automatic transition rules Limitations • Only possible on exec • No transition during program run • No transition if external code is executed as module

12. Transitions Example • Remote login (ssh) • automatic transition into default role and type as the sshd forks the shell • execute a program that has a domain defined (screen) • transition into that domain on program execution

13. Security Advantages • A fairly complex system • What are the advantages?

14. Security Advantages Roles and Domains: • Domains can be completely separated • Roles follow the minimum-privilege rule • Exploits do not break the entire system • ...even if root account is compromised • Untrusted code can be contained

15. Security Advantages Example for RBAC setup • Four roles • Separation of duties • Overlaps where necessary • Remember: Users can switch roles – the DBA and WebAdmin might be the same person

16. Security Advantages Policy and Enforcement: • Very fine-grained access controls (syscall level) • Even tiny violations can be monitored • Management by policy, not user-actions • Minimizes damage that user mistakes can cause • Forces users to follow policy

17. The Policy • Uses a simple declarative language • M4 macros • Simple file system structure • GUI Tools are becoming available • A default policy is supplied

18. Demonstration

19. Installation • Download and compile the sources from the NSA website or sourceforge.net • Packages are available for Debian, Gentoo, SuSE and Redhat • The important part: The policy • Do not forget: make relabel • Begin with: permissive mode

20. Links • http://www.nsa.gov/selinux/ • http://sourceforge.net/projects/selinux/ • http://www.securityenhancedlinux.de • http://selinux.lemuria.org

21. Thank you Please ask questions Security Enhanced Linux