1. Security-Enhanced Linux Joseph A LaConte CS 522 December 8, 2004

2. Joseph A. LaConte2 Overview Background –Overview and Goals –Previous Projects –Why Linux SELinux –Overview –MAC versus DAC –Security Policy Implementations Type Enforcement Role-Based Access Control Policies Limitations

3. December 8, 2004Joseph A. LaConte3 Background Security-Enhanced Linux is a NSA (National Security Agency) backed research project. Goals: –Promote Security Research –Address Operating System Security –Demonstrate MAC (Mandatory Access Controls) through Type Enforcement® technology in a mainstream operating system Note: SELinux project is not intended as a complete security solution for Linux

4. December 8, 2004Joseph A. LaConte4 Background In Conjunction with Secure Computing Corporation (SCC) Previous projects: LOCK system – Secure Ada project through Honeywell DTMach – Mach-based prototype DTOS (Distributed Trusted Operating System) Fluke* - University of Utah's research operating system Flask architecture* * - Fluke was a pre-existing operating system used by the Flux Research group at Utah. During the integration/transfer of technology into the system, enhanced dynamic security policies were produced. The resulting architecture is named Flask.

5. December 8, 2004Joseph A. LaConte5 Background Why choose Linux? As hinted in the goals, Linux is an open source project with many developers; therefore: Provides an opportunity for more research. Allows application/testing in a mainstream operating system. Improves security in an existing operating system.

6. December 8, 2004Joseph A. LaConte6 SELinux Security-Enhanced Linux (SELinux) –Uses the Linux Security Modules (LSM) framework to implement flexible Mandatory Access Control (MAC) in the Linux kernal. –Restricts privileges of user programs and system servers using security labels and an administratively- defined policy.

7. December 8, 2004Joseph A. LaConte7 SELinux MAC versus DAC Discretionary Access Control (DAC) is the standard security model for Linux. In this model, access privileges are based on the user identity and object ownership. Mandatory Access Control (MAC) limits privileges for subjects (processes) and objects (file, socket, device, etc). Please note: SELinux does not change any existing security in the Linux environment; rather, SELinux extends the security model to include Mandatory Access Control (i.e. both MAC and DAC are enforced in the SELinux environment).

8. December 8, 2004Joseph A. LaConte8 SELinux Security Policies are implemented using: –Type Enforcement ® (TE) –Role-based access control (RBAC)

9. December 8, 2004Joseph A. LaConte9 Type Enforcement (introduced in 1985 by Boebert and Kain) Traditional TE model uses a domain attribute for each process and a type attribute for each object. User operation is limited to certain domains. In SELinux, a single attribute is used for both subject and object (“A domain is simply a type that can be associated with a process“). Security classes can distinguish objects of the same type. Uses the RBAC model instead of associating users with domains. An access matrix defines the privileges of each type for a given domain.

10. December 8, 2004Joseph A. LaConte10 Role-Based Access Control Each user gets a set of roles Each role is assigned a set of TE domains. Note: users are not identified by Linux uids; instead a user identity attribute is used in the security context.

11. December 8, 2004Joseph A. LaConte11 Policies Configuration consists of : Flask definitions TE and RBAC declarations and rules User declarations Constraint definitions Security context specifications.

12. December 8, 2004Joseph A. LaConte12 Policies TE Statements –Attribute Declarations –Type Declarations –TE Transition Rules –TE Change Rules –TE Access Vector Rules –TE Access Vector Assertions –Type Member Rules RBAC Statements –Role Declarations and Dominance –Role Allow Rules –Role Transition Rules

13. December 8, 2004Joseph A. LaConte13 Policies Syntax for TE and RBAC declarations* Syntax for type declarations* * Smally, Stephen January 2003.

14. December 8, 2004Joseph A. LaConte14 Policies Bleher, Thomas November 30, 2004

15. December 8, 2004Joseph A. LaConte15 Limitations Performance Overhead – calculated at approximately 7%. Complexity – requires in-depth knowledge of the operating system, the security policies, and the operating environment. Maintenance – policy fine-tuning, changes required for changes to the system.

16. December 8, 2004Joseph A. LaConte16 References National Security Agency. Security Enhanced Linux, December 8, 2004. http://www.nsa.gov/selinux/index.cfm Thompson, Kerry. The UnOfficial SELinux FAQ, June 15, 2004. http://www.crypt.gen.nz/selinux/faq.html Wade, Karsten. Fedora Core 3 SELinux FAQ, November 9, 2004. http://fedora.redhat.com/docs/selinux-faq- fc3/index.html Smally, Stephen. Configuring the SELinux Policy, February 2002, revised January 2003. NAI Labs. Secure Computing Corporation. The Origin of Sidewinder® G2 Firewall, December 8, 2004. http://www.securecomputing.com/index.cfm?skey=1024

17. December 8, 2004Joseph A. LaConte17 References OSDGroup LLC. Module 13 – SELinux Overview, December 8, 2004. http://www.bradfordlearning.com/en/courseware/sample_ch apters/se_linux_sample_chapter.pdf SourceFORGE.net. SELinux Background, December 8, 2004. http://selinux.sourceforge.net/background.php3 Hallyn, Serge Edward. Domain and Type Enforcement in Linux. The College of William and Mary in Virginia. Bleher, Thomas. Source file: domains/program/apache.te (patch), November 30, 2004.