Chapter 9 Building a Secure Operating System for
Chapter 9 Building a Secure Operating System for Linux
Chapter Overview • • Linux Security Modules – History – Implementation Se. Linux – Reference Monitor – Protection State – Labeling State – Transition State – Administration – Trusted Programs – Security Evaluation
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 App. Armor • Will try to cover SELinux
LSM History • Lots of early security work on Linux: – Argus Pit. Bull – LIDS – Subdomain (App. Armor) – RSBAC – GRSecurity – DTE for Linux – Medusa DS 9 – Open Wall – HP's initiative – Flask (SELinux)
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
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. 1 e capabilities mechanism as an “optional security module”.
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
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 App. Armor, so App. Armor is also available.
LSM Implementation • LSM Framework implemetation has three parts: – – – Reference monitor interface definition Reference monitor interface placement Reference monitor implementation
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.
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.
LSM Hook Architecture
LSM Reference Monitor Implementation • Each LSM reference monitor is different. • However, most security enhanced versions of Linux use the same hooks. • Exception is RSBAC
Security-Enhanced Linux
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. • Subjects and objects have labels, called contexts • These contexts are checked. The authorization checker has four arguments: – – Subject context Objects data type Requested operation
SELinux Protection State
SELinux Contexts
SELinux Contexts • 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!
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.
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.
SELinux Administration • Different kinds of policies: – – • Monolithic Modular Policy development: – – – Strict policy Targeted (like App. Armor) Reference Policy
SELinux Trusted Programs
SELinux Security Evaluation
- Slides: 23