1. Server Security 1 SE Linux, Systrace Lars Noodén (lars.nooden@gmail.com) March – April 2009

2. Server Security 2 Phases of Development production / release - point version – minor changes release candidate – make sure beta – functions and interface work as expected alpha – no new functions, rudimentary implementation prototype – decide all functions interface proof-of-concept – implement key functions mock-up – fake how it should be

3. Server Security Example ● gmail now in 5th year of beta

4. Server Security 4 Production Phase ● systrace and SELinux only really practical to deploy in production phase or near production phase ● deployment of either requires lots of testing and monitoring – intrusion detection – correct policy errors

5. Server Security Definition ● least privilege – Users and programs should be given only what is needed to accomplish their tasks – limits damage from errors – limits damage from compromise ● privilege separations – application split into parts for different tasks and each part runs with different levels of privilege

6. Server Security 6 Least Privilege Users and programs should be given only what is needed to accomplish their tasks ● limits damage from errors ● limits damage from compromise Privileges ● write XOR execute ● read, write, execute ● read, edit, create, delete, execute, lookup, admin ● insert, update, delete, index, alter, create, drop, grant, lock, file, etc.

7. Server Security 7 Layers ● Like the networks, operating systems are generally built up in layers – the most basic, essential tasks at the center/bottom ● Each layer only needs to communicate with the adjacent layers – can replace, modify, or upgrade as desired. – contributes to the overall robustness of the system

8. Server Security 8 Kernel Operating System ● User interface (optional) ● User applications ● Operating system services (optional) ● System calls ● Kernel services (Microkernel) ● Device drivers ● Hardware kernel manages all system resources

9. Server Security 9 Compartmentalization SE Linux ● kernel-level mandatory access control ● limit which files a daemon may use systrace ● compartmentalization by intercepting system calls ● limit which system calls may be used by a daemon

10. Server Security 10 SE Linux

11. Server Security 11 SE Linux ● Support for mandatory access control ● Fine-grained security domains – e.g. customized domains for specific applications ● US National Security Agency (NSA) – Background and technical documentation: ● http://www.nsa.gov/selinux.

12. Server Security 12 SE Linux Modes ● disabled – SE Linux turned off ● permissive – audit instead of deny – code proceeds but is monitored ● enforcing – deny and audit – stops anything not explicitly allowed – prevents code from proceeding past first denial

13. Server Security 13 SE Linux Policies ● SE Linux Policy is a set of MACLs ● Only one active policy at a time, per machine – however, choice of many policies per machine ● Policies can be – temporary, or – persistent ● Two kinds of policies – targeted – most processes without restrictions – strict – all processes confined by policies

14. Server Security 14 Security Context or Label Each and all system components have their own label and fit in a context ● files (everything is a file, anyway) – programs ● data ● devices (those are files, too) ● directories (same) ● etc.

15. Server Security 15 Security Context or Label Each and all system components have their own label and fit in a context ● user ● role ● type ● range

16. Server Security 16 SE Linux Example Policies (from manual pages)

17. Server Security 17 SE Linux Policies ● Policies govern access to files by daemons ● Some services have more than one daemon – Moodle = Apache (httpd) + MySQL (mysqld) – using files in more than one domain is possible ● system-config-selinux – – a GUI tool to customize SELinux policies

18. Server Security 18 ftpd_selinux(8) ● Anonymous FTP – data transfer – no login – public, read-only – more efficient than http, less than rsync

19. Server Security 19 httpd_selinux(8) ● web server – http and https – public data – read-only, unless WebDAV is used – with or without internal scripting – loadable modules run under same context as httpd

20. Server Security 20 samba_selinux(8) ● samba – smb/cifs services – print – file ● read, write, etc – user management ● authorization ● access – can be combined with Apache

21. Server Security 21 kerberos_selinux(8)

22. Server Security 22 rsync_selinux(8)

23. Server Security 23 Further Reading ● http://www.nsa.gov/research/selinux/ ● http://www.nsa.gov/public_info/press_room/2001/se- linux.shtml

24. Server Security 24 SE Linux Tools

25. Server Security 25 Some SE Linux Tools ● Make policy allow rules from logs of denied operations – audit2allow(1) ● Translate audit messages into descriptions of why access was denied – audit2why(1) [see also: audit2allow -w] ● SELinux graphical audit log analysis – seaudit (8) ● SELinux audit log reporting – seaudit-report (8)

26. Server Security 26 ● pam_sepermit (8) - PAM module to allow/deny login depending on SELinux enforcement state

27. Server Security 27 systrace

28. Server Security 28 systrace ● fine-grained compartmentalization ● re-writes syscall (system call) arguments ● multiple-policies – policy generation ● automatic, or ● interactive – policy enforcement

29. Server Security 29 systrace Supported in ● Linux, ● OpenBSD, ● NetBSD

30. Server Security 30 Kernel Operating System ● User interface (optional) ● User applications ● Operating system services (optional) ● System calls ● Kernel services (Microkernel) ● Device drivers ● Hardware

31. Server Security 31 Systrace in the Kernel ● policies deny, allow – inside kernel – ask – request decision about system call – information via /dev/systrace

32. Server Security 32 Systrace Userland ● external systrace application ● all monitored processes killed if systrace killed ● policy configuration – flat directory structure – /etc/systrace/ – for global policies – ~/.systrace/ – for per-user configurations

33. Server Security 33 Process ● matches deny – reject ● matches allow – permit ● none of the above – ask user – automatic enforcement mode – automatic denial – automatic generation mode – new policy made

34. Server Security 34 System Call Process w/systrace Sandbox Kernel System Call Gateway Systrace In-Kernel Policy Permit/ Ask Deny Application System Call Systrace Userland Translate Policy Decision Ask? Policy Permit! / Deny! Inform User for Decision Source: Niels Provos: http://www.citi.umich.edu/u/provos/papers/systrace.pdf

35. Server Security 35 Sample Benchmark ● systrace overhead: Program Real User System find /usr/src/ \ >/dev/null 30 0.2 0.3 systrace find /usr/src/ \ >/dev/null 42 1.2 3.8 Find has a high overhead because of many open calls. About 57k files in that subdirectory. Source: Niels Provos: http://www.citi.umich.edu/u/provos/papers/systrace-lsm/mgp00018.txt

36. Server Security 36 Sample Benchmark ● systrace overhead: Program Real User System gzip -9 test.bin 2.0 1.7 0.1 systrace gzip -9 test.bin 1.9 1.6 0.1 Gzip has no noticeable overhead because it is mostly CPU bound. 10 Mbyte file was compressed. Source: Niels Provos: http://www.citi.umich.edu/u/provos/papers/systrace-lsm/mgp00018.txt

37. Server Security Further Reading Systrace http://www.citi.umich.edu/u/provos/systrace/

38. Server Security 38 Server Security SE Linux, Systrace Lars Noodén (lars.nooden@gmail.com) March – April 2009