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
December 8, 2004
Joseph A. LaConte
2
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
December 8, 2004
Joseph A. LaConte
3
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.
December 8, 2004
Joseph A. LaConte
4
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.
December 8, 2004
Joseph A. LaConte
5
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 administrativelydefined policy.
December 8, 2004
Joseph A. LaConte
6
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).
December 8, 2004
Joseph A. LaConte
7
SELinux
Security Policies are implemented using:
– Type Enforcement® (TE)
– Role-based access control (RBAC)
December 8, 2004
Joseph A. LaConte
8
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.
December 8, 2004
Joseph A. LaConte
9
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.
December 8, 2004
Joseph A. LaConte
10
Policies
Configuration consists of:
•
•
•
•
•
Flask definitions
TE and RBAC declarations and
rules
User declarations
Constraint definitions
Security context specifications.
December 8, 2004
Joseph A. LaConte
11
Policies
TE Statements
–
–
–
–
–
–
RBAC Statements
Attribute Declarations
Type Declarations
TE Transition Rules
TE Change Rules
TE Access Vector Rules
TE Access Vector
Assertions
– Type Member Rules
December 8, 2004
– Role Declarations and
Dominance
– Role Allow Rules
– Role Transition Rules
Joseph A. LaConte
12
Policies
Syntax for TE and RBAC declarations*
Syntax for type declarations*
* Smally, Stephen January 2003.
December 8, 2004
Joseph A. LaConte
13
Policies
Bleher, Thomas November 30, 2004
December 8, 2004
Joseph A. LaConte
14
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.
December 8, 2004
Joseph A. LaConte
15
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
December 8, 2004
Joseph A. LaConte
16
References
OSDGroup LLC. Module 13 – SELinux Overview, December 8,
2004.
http://www.bradfordlearning.com/en/courseware/sample_cha
pters/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/cgibin/archzoom.cgi/tbleher@gmx.de--selinux/policy--suse--0-patch-12?log>
December 8, 2004
Joseph A. LaConte
17