1 / 17

Security-Enhanced Linux

Security-Enhanced Linux. Joseph A LaConte CS 522 December 8, 2004. 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. Background.

marlo
Télécharger la présentation

Security-Enhanced Linux

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 Joseph A. LaConte

  3. 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® technologyin a mainstream operating system Note: SELinux project is not intended as a complete security solution for Linux Joseph A. LaConte

  4. 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. Joseph A. LaConte

  5. 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. Joseph A. LaConte

  6. 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. Joseph A. LaConte

  7. 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). Joseph A. LaConte

  8. SELinux Security Policies are implemented using: • Type Enforcement® (TE) • Role-based access control (RBAC) Joseph A. LaConte

  9. 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. Joseph A. LaConte

  10. 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. Joseph A. LaConte

  11. Configuration consists of: Flask definitions TE and RBAC declarations and rules User declarations Constraint definitions Security context specifications. Policies Joseph A. LaConte

  12. 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 Policies Joseph A. LaConte

  13. Policies Syntax for TE and RBAC declarations* Syntax for type declarations* * Smally, Stephen January 2003. Joseph A. LaConte

  14. Policies Bleher, Thomas November 30, 2004 Joseph A. LaConte

  15. 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. Joseph A. LaConte

  16. 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. <URL:http://www.nsa.gov/selinux/papers/policy2-abs.cfm> Secure Computing Corporation. The Origin of Sidewinder® G2 Firewall, December 8, 2004. http://www.securecomputing.com/index.cfm?skey=1024 Joseph A. LaConte

  17. References OSDGroup LLC. Module 13 – SELinux Overview, December 8, 2004. http://www.bradfordlearning.com/en/courseware/sample_chapters/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. <URL:http://www.cs.wm.edu/~kearns/dissertations.d/serge.pdf> Bleher, Thomas. Source file: domains/program/apache.te (patch), November 30, 2004. <URL:http://www.cip.ifi.lmu.de/~bleher/cgi-bin/archzoom.cgi/tbleher@gmx.de--selinux/policy--suse--0--patch-12?log> Joseph A. LaConte

More Related