Secureworld Conference

Transcription

1 P14 Emily Ratliff Advances in Linux Security: The Linux Security Modules Project Secureworld Conference 1 n

2 Legal Statement This work represents the views of the author and does not necessarily reflect the views of IBM Corporation. The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries: IBM (logo), e-business (logo). A full list of U.S. trademarks owned by IBM may be found at Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others. 2

3 Agenda What is LSM? Why you care History Currently available modules Recap 3

4 What is LSM? Linux Security Modules (a.k.a. Loadable Security Modules) Hooks that allow you to customize your security policy by loading a kernel module New feature in v. 2.5 Kernel patch against ~131 hooking functions defined in include/linux/security.h example: inode, file, ipc, msg_queue, module, task, etc. Resources Mailing list archives Web 4

5 Why you should care about LSM Whole new world of security policies will be open to you with the arrival of v.2.6 Alternate security policies will be included in kernel and available by default Customization of security policy now much easier Minimize support costs of maintaining kernel patches that change security policy LSM enables tiny changes that otherwise would not have been worth the cost Researchers/administrators can easily experiment with various security policies 5

6 What can LSM do for you? Extremely Simple Example: log all file opens With LSM code in one hooking function compile module insmod module Without LSM change code in fs/open.c recompile kernel install kernel reboot to new kernel 6

7 History of LSM - First Kernel Summit First 2.5 Kernel Summit March 2001 NSA proposed that Security Enhanced Linux be integrated into kernel. Issue lots of competitors to SELinux: LIDS, RSBAC, Medusa DS/9 Decision: no winner Better way loadable security modules - LSM implement hooks to allow security enhancements (specifically access controls) to load as modules 7

8 History of LSM - Kernel Summit 2002 A core LSM developer presented initial implementation Networking worried about performance impact No major input Two Work items flatten the hooks (no more double indirection) Consider making use of networking hooks configurable 8

9 History of LSM - Inclusion in v2.5 Plan behind submission first submit non-lsm prerequisite patches (in ) break LSM up into logical pieces based on subsystem submit a subsystem at a time, less controversial subsystems first First LSM hooks were accepted in (basic framework + task hooks) Trusted Linux community member submitted most of the LSM patches various community members created the patches LSM networking specialist submitted networking patches 9

10 History of LSM The Battle for the Network Hooks Getting the network hooks in was a battle Network maintainer's initial response was extremely negative unmaintainable skb_set_owner_w: "millions upon millions of times a second on a busy server" now hooks are configurable CONFIG_SECURITY CONFIG_SECURITY_NETWORK hooks in low level interfaces were rejected as unmaintainable No longer supports network packet labeling 10

11 Available LSM Modules Where to find out more about LSM modules: List of modules that the community description link to project home 11

12 SELinux NSA's Security Enhanced Linux Information Assurance role of the NSA Mandatory Access Control (MAC) architecture Separation between policy and enforcement engine Default policies provided Type Enforcement Role Based Access Control Experimental MLS policy Security context (collection of attributes) per process and object Caches access decisions for speed 12

13 SELinux Russell Coker's SELinux play machine Gentoo and Debian have hardened distros that include SELinux RedHat announced for 2H04 13

14 LIDS Linux Intrusion Detection System Began as intrusion detection Grew to encompass Mandatory Access Control In-kernel port scan detector File control ACL implementation Attribute control (append, hide, read-only) Process attributes: un-killable or hidden Intrusion response end user's session to administrator log 14

15 DTE Domain Type Enforcement an access control technology for partitioning host operating systems such as UNIX into access control domains USENIX Security '95 "A DTE UNIX Prototype" Badger, et al Subject - process Object - passive entities: files, named pipes, shared memory segment, etc. Type - attributes associated with objects: read, write, execute Domain - associated with processes: definition of activities that a subject is allowed to perform Cross-domain capabilities also defined example, whether a process can signal another Limits power of processes running as root defeats many remote root exploits 15

16 DISEC Ericsson's Distributed Security Infrastructure Provides coherent secure framework for telecom applications running on carrier class Linux clusters Secure intra-cluster communication Dynamic security policy Change underlying security policy without interrupting running processes (availability) Cluster coherency of security policy Nodes view security of the cluster and the node Network packets between nodes labeled 16

17 Owlsm LSM based on OpenWall kernel patch popular kernel patch by Solar Designer Security Tweaks Enforces resource limits on exec Secure handling of file descriptors 0, 1, 2 Prevent users from creating hard links to files that they don't own Prevent users from following symbolic links in directories where the sticky bit is set (ex. /tmp) Defeats /tmp attacks Zero administration cost 17

18 TPE Trusted Path Execution Essentially limits untrusted users to running system binaries TPE helps defeat local exploits by preventing users from downloading and executing exploit code Implementation trusted users list trusted path directory root owned and neither group nor other writable Can execute binary in: trusted path untrusted path trusted user Yes Yes untrusted user Yes No 18

19 rootplug First module to make it into kernel Meant as an example module originally written as a Linux Journal article Prevents root from executing processes unless a certain USB device is present on the system 19

20 What you should know before developing your module LSM is GPL'd like the rest of the kernel. Unlike module.h, security.h explicitly states that it is GPL'd. security.h must be #included in security modules potential (ugly) workarounds were discussed on the mailing list current (untested) understanding that kernel modules don't have to be GPL'd unclear whether this means that LSMs must be GPL'd but community does believe that LSMs must be GPL'd 20

21 Conclusion LSM is a mechanism to customize your security policy without applying patch and recompiling kernel or even rebooting. LSM has been added to the 2.5 version of the Linux kernel. LSM's value is that you can address unique security needs quickly without making invasive hard-to-support changes to the kernel. 21

22 Backup Charts P14 Emily Ratliff Linux Security Modules Project Backup Charts Secureworld Conference 22 n

23 Technical Issues system call interposition vs. hooks commonly used rejected for performance reasons, access to code made this implementation unnecessary system call table symbol not exported in v. 2.5 restrictive vs. authoritative hooks current implementation: restrictive modules can override yes with no, but can't override no with yes authoritative more expressive helpful for audit and ACL modules more invasive slightly more code LSM committers don't like it will be considered in Phase 2 23