1. Chapter 9 Building a Secure Operating System for Linux

2. Chapter Overview Linux Security Modules – History – Implementation SeLinux – Reference Monitor – Protection State – Labeling State – Transition State – Administration – Trusted Programs – Security Evaluation

3. Linux Security Modules Reference Monitor System for the Linux kernel. Consists of two parts: – Reference Monitor Interface – Reference Monitor Module (LSM) Several LSM's have been implemented. Have covered AppArmor Will try to cover SELinux

4. LSM History Lots of early security work on Linux: – Argus PitBull – LIDS – Subdomain (AppArmor) – RSBAC – GRSecurity – DTE for Linux – Medusa DS9 – Open Wall – HP's initiative – Flask (SELinux)

5. LSM History (II) Obviously, (2001) a reference monitor was necessary for Linux; everybody was reinventing the wheel! But: – Linus Torvalds was not a security expert, could not decide on an approach – There was no real agreement as to which was the “best” approach. Result was a design basde on kernel modules with a single interface for all the necessary modules. LSM framework

6. LSM Requirements: The reference monitor must be truly generic, so that switching to a different security model was simply a matter of loading a different kernel module. The interfaces must be “conceptually simple, minimally invasive, and efficient.” Must support the POSIX.1e capabilities mechanism as an “optional security module”.

7. Design of the reference monitor Formed union of all projects to date. Restricted number of authorization queries to prevent redundant authorizations. Manual design, source code analysis tools were used to verify completeness and consistency, finding six bugs. Most of the interface had negligible performance impact except for the CIPSO implementation. Network security is now supported inoe of two ways: – Labeled IPSec – New implementation of CIPSO called Netlabel

8. LSM History, final details LSM framework was officially added to Linux kernel in version 2.6. SELinux and POSIX capabilities were included with the release of LSM Novell bought the company that supported AppArmor, so AppArmor is also available.

9. LSM Implementation LSM Framework implemetation has three parts: – Reference monitor interface definition – Reference monitor interface placement – Reference monitor implementation

10. LSM Reference Monitor definition Specifies the way the kernel can invoke the LSM reference monitor. The description is in the file include/linux/security.h in the kernel sources. It defines a structure security_operations with all the LSM function pointers. They are called LSM hooks. 150 hoks for authorizations, plus other hooks for labels, label transitions. And label maintenance.

11. LSM Reference Monitor placement Where to place the hook? – At the entrance to the system call? – What about TOCTTOU attacks? – What about the “open” system call? The hooks were placed using in-line function declarations.

12. LSM Hook Architecture

13. LSM Reference Monitor Implementation Each LSM reference monitor is different. However, most security enhanced versions of Linux use the same hooks. Exception is RSBAC

14. Security-Enhanced Linux

15. SELinux Reference Monitor Two distinct processing steps.: – Convert input values from the LSM hooks into one or more authorization queries. – Check against SELinux protection system.

16. SELinux Protection State

17. SELinux Contexts

18. Previous diagram gave idea of user labels;; each context has permissions assigned to it. There is also an MLS policy, but, though it allows read down, it only allows write level. Both type labels and MLS labels are checked. 20 different object data types, and many operations, including read, write, execute, create, ioctl, fcntl, extended attributes,.. Over 1000 state labels. Very complex administration!

19. SELinux Labeling State Files/objects are labeled (by default) based on their location in the file system, but file contexts can be used to override the defaults. Labels are inherited. For files, the label of a file is inherited from the label of its parent directed, some processes may have permission to relabel them.

20. SELinux Transition State Rather than SUID programs, a label transition is only allowed at execution; the transition only gives limited privileges; also, not all programs can run a transitioning prtogram. Instead of gatekeepers, SELinux relies onprogrammers to keep program safe.

21. SELinux Administration Different kinds of policies: – Monolithic – Modular Policy development: – Strict policy – Targeted (like AppArmor) – Reference Policy

22. SELinux Trusted Programs

23. SELinux Security Evaluation