Enabling Business through SELinux
Doc Shankar
IBM Distinguished Engineer
dshankar@us.ibm.com
Agenda
•
•
•
•
•
•
•
•
Basic Access Control Concepts
SELinux Concepts
SELinux based MLS/Linux (LSPP Certified)
SELinux Value
SELinux Prevented Exploits
SELinux Solutions
SELinux Today
SELinux Tomorrow
2
Access Control Requirements
• Reference Monitor
– Concept arose from Anderson's report—research in early 1970s
to address government computer security concerns.
– Small security-enforcing mechanism is core of TCB.
– Active entities—processes—are subjects.
– Passive entities—system resources—are objects.
– Both subjects and objects have security attributes.
– The reference monitor consults rules to make decisions based
on security attributes.
– It typically logs decisions so actions can be audited.
• 3 Fundamental Properties
– Completeness
– Tamperproofness
– Correctness
3
4
DAC - Concepts
• Traditional UNIX owner-group-other access
control model and, optionally, ACLs
• Two roles: superuser and ordinary user
• Access to objects at owner’s discretion
• Access mode can be modified by the owner
or programs running on behalf of the owner
• Enforcing mechanism and rules hard-coded
in the kernel
5
MAC - Concepts
• Derived from separation required by
military environments
• Administrator (and not the owner) has full
control over allowed access
• Programs running on behalf of a user are
constrained by the administrator controlled
security policy
• Rules can be hard-coded in the kernel or
configurable
6
DAC vs MAC
Discretionary Access Control
•
Familiar, easy to understand
•
model used by most operating systems
•
users have control (discretion) over their files and
programs
•
programs run as a user have that user's privileges
•
root/superuser has complete control
•
Trusted programs often run as superuser
•
attacker's goal is to exploit program running with
root privileges
•
Superuser privileges harder to breakup
Mandatory Access Control

Newer concept, hard to grasp

Not part of mainstream OS

program privileges under the control of security
policy

easier to implement principle of least privilege

supplements DAC

Trusted programs privileges also under the control
of security policy

Attacker is contained

Role separation
Policy
Kernel
Kernel
Enforcement
Discretionary Access Control
Once a security exploit gains access to
privileged system components the entire
system is compromised
Mandatory Access Control
Kernel policy defines application rights,
firewalling applications from compromising
the entire system
7
Domain-Type Enforcement (DTE)
• Developed in 1980s by Boebert and Kain.
• Subjects are in domains and objects have types.
• Think of domains and types as equivalence
classes for processes and resources, respectively.
• Flexible and configurable policy implements MAC
rules that mediate access between all domains and
types. Very rich and granular.
• Many MAC models can be expressed in terms of
DTE.
• Policies can be difficult to develop and analyze.
8
SELinux TE
• Both domains and types implemented as types. Subject
types are sometimes referred to as domains
• Non-authoritative—DAC can deny first.
• Default is to deny everything; policy specifies allows.
• All objects receive context labels, via xattrs if possible.
• Users are assigned a context upon login.
• Each process transitions into its domain on exec.
• The SELinux Security Server makes decisions on
whether a domain can access a type by examining the
context labels and consulting the policy
• Security policy specifying MAC rules is configurable and
can be changed dynamically
• MAC rules are specified for subject domains, object
types and object classes
9
TE – Access Control Example
• Users Bob, Alice, Jack and Jill are part of a software
development project
• Upon login they are placed in domain proj_member_t
• Project files are of type proj_files_t
• The security policy allows subjects in proj_member_t
domain read access to files of type proj_files_t
proj_member_t
read
proj_files_t
10
TE/RBAC – Access Control Example
• Alice, Bob and Jill are developers, Jack writes design
documents, and Alice is also the project lead
• Changing roles puts users in appropriate domains,
for example, changing role to developer_r puts the
user in domain proj_devel_t
proj_doc_t
proj_member_t
read
proj_devel_t
proj_files_t
proj_docs_t
proj_lead_t
11
SELinux Overview
• Created by NSA through series of research projects in the
1990s
• Based on the Flask architecture developed by NSA, SCC,
and University of Utah
• Originally a huge kernel patch, which Linus disliked.
• Led to creation of Linux Security Module (LSM) architecture.
• Implemented as a set of LSM hooks.
• Separates policy from implementation.
• Flexible TE policy language is excruciatingly granular.
• Orthogonal to DAC; non-authoritative-can only deny.
• RBAC—roles aggregate types a user can take on.
• MLS implemented as an additional constraint on the TE
policy
12
SELinux Operation
13
Linux Meets Trusted Common Criteria
 Linux has been evaluated at EAL4+ against CAPP,
LSPP and RBACPP
 Trusted evaluation completed June 2007
 Available on Red Hat’s RHEL5
 All IBM Server Platforms are evaluated for Trusted
Linux
 Linux is now the most evaluated operating system
 LSPP evaluation includes more HW platforms than
any other OS
– Scale up, scale out
 Commoditization of government quality security
– Cost savings for government
– Government style security widely available
 Revalidation of open source development
methodology
14
What does it take to get LSPP Certified at EAL4+?
“Methodically Designed, Tested, and Reviewed”
•
•
Community Development
–
–
–
MLS Policy
Labeled
Networking
Labeled Printing
–
–
Audit Enhancements
Polyinstantiation
Assurance
–
–
–
–
Security Target: 106 pages
Protection of TOE Security Functions
(amtu)
Configuration Management (CVS)
Delivery & Operations: ~100 pages
•
–
Development Documents
•
Common Criteria Effort
•
•
•
–
Security Target
Protection of TOE
Config Mgmt
Delivery & Operations
FSP
HLD
LLD
Other Dev Docs
Guidance Docs
Life Cycle
Security Testing
Vulnerability Assessment
–
Flaw remediation, security patch
process
Testing
•
•
–
User, Security & Admin Manuals
Life Cycle
•
Functional Development
Functional Specification: hundreds of
man pages
High Level Design: 271 pages
Low Level Design: ~ 800 pages
Security Policy Model: 11 pages
Guidance Documentation: ~825
pages
•
–
Install & Configuration Manuals
Test plan
1200 test cases
Vulnerability Assessment: ~ 50 pages
15
LSPP Community
• A true open source effort - challenging
• IBM sponsors a weekly teleconference (open telecon)
– 60+ participants from 14+ organizations on the invitation
• IBM, Red Hat, NSA, @sec, HP, TCS, Tresys, OSDL, and PSU +
various individuals
– All development takes place on open mailing lists
• Development goes upstream and is collected in rawhide
– Fedora Rawhide provides daily builds
– Red Hat hosts test kernels for features pending kernel maintainer
acceptance
• Real users provide feedback during development
• Schedule
– In Evaluation (09/05)
– Development Complete (03/07)
– Certification Complete (06/07)
16
SELinux Value
•
•
•
•
•
•
•
•
•
•
•
•
Designed by NSA to meet government security requirements now and in the future
SELinux + MLS modifications accepted into the kernel
SELinux is flexible—many different MAC models can be implemented in terms of it
Restrictive Security (DAC + TE + MLS)
Part of mainline OS – not an add-on
Supported in RHEL 5
Meets Common Criteria Labeled Security Protection Profile (LSPP) MLS
requirements at EAL4+ (Single cert. covers 7 platforms)
Targeted (confinement) policy enabled by default in RHEL 5
Strict (least privilege) and MLS policies also supported
Requires fewer specialized skills compared to special-purpose trusted OS's
Has Open Source test suite to demonstrate LSPP compliance during C&A
Mitigate the effects of common attacks that DAC cannot:
–
–
•
•
•
•
•
Trojan horse
Buffer overflow
Decompose root privileges.
Extensively analyzed for correctness
Free software – customers can inspect & maintain source code as necessary
Draws a vibrant community including end customers
Provides an alternative to Trusted Solaris.
17
SELinux Prevented Exploits*
• NYSE
http://james-morris.livejournal.com/30367.html
• Firefox plug in protection
http://danwalsh.livejournal.com/17727.html
• Mambo code injection exploit blocked:
http://www.linuxjournal.com/article/9176
• Open Pegasus stack buffer overflow
https://rhn.redhat.com/errata/RHSA-2008-0002.html
• HP Linux Imaging & printing erroneous input
https://rhn.redhat.com/errata/RHSA-2007-0960.html
• Samba Buffer overflow
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2447
• Linux kernel local privilege escalation (0 day exploit)
https://www.redhat.com/archives/fedora-selinux-list/2006-July/msg00071.html
*Not a complete list (more on http://www.tresys.com/innovation.php)
18
SELinux based Solutions*
• UK Government eCabinet office
• US Coast Guard
• Trusted Computer Solutions
– Trusted Thin Clients
– Trusted Guards
•
•
•
•
•
Tresys (WebSphere, DB2)
NSA HAP
MLS Applications (TNE)
CDS Applications (Guards)
Cross Domain SOA
*Not a complete list
19
SELinux Today
Confine
Damage from
Hacked Programs
Precise Control
Over
Permissions
DONE?
SELinux
RBAC
Brickwall
LSM
MLS
Linux
LSPP
semanage
EAL4+
Modular policy
Remove
Dependence on
Root
setroubleshoot
Limit User and
Application
Privileges
Increasingly widespread deployment in public sector
20
SELinux Tomorrow
SMB Market /
Ease of Use
Broader
deployment
Cross-OS
Common Domain
of Interpretation
Standardizatio
n
DONE? NO
“How do we
turn it off?”
SELinux
RBAC
Brickwall
Enterprise
Management
Centralized
Policy
Mgmt
LSM
MLS
ISV Policy
Creation
Linux
LSPP
semanage
Policy
Abstraction
EAL4+
Modular policy
Database Label
Integration
Application
Level Security
setroubleshoot
Trusted X
Windows
Mandatory
Encryption
Policies
Real-Time +
SELinux
Technology
Horizon
21
Thank You!
. . . Any Questions?
22
Trademarks and Presentation Notes
•
The following are trademarks of the International Business Machines Corporation in the United States and/or other countries. For a
complete list of IBM Trademarks, see www.ibm.com/legal/copytrade.shtml: eServer, System x, System p, System i, System z, IBM.
•
•
The following are trademarks or registered trademarks of other companies:
Java and all Java based trademarks and logos are trademarks of Sun Microsystems, Inc., in the United States and other countries or
both
Microsoft, Windows,Windows NT and the Windows logo are registered trademarks of Microsoft Corporation in the United States, other
countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Red Hat, Red Hat Linux are registered trademarks of Red Hat, Inc.
SUSE is a registered trademark of Novell, Inc.
Other company, product, or service names may be trademarks or service marks of others.
•
•
•
•
•
•
Any statements about support or other commitments may be changed or cancelled at any time without notice. All statements regarding IBM's
future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only Information is provided
“AS IS” without warranty of any kind.
•
This publication was produced in the United States. IBM may not offer the products, services or features discussed in this document
in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for
information on the product or services available in your area.
•
Information about non-IBM products is obtained from the manufacturers of those products or their published announcements. IBM
has not tested those products and cannot confirm the performance, compatibility, or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
•
The information could include technical inaccuracies or typographical errors. Changes are periodically made to the information
herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the
product(s) and/or the program(s) described in this publication at any time without notice.
•
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an
endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those
Web sites is at your own risk.
•
IBM makes no representation or warranty regarding third-party products or services including those designated as ServerProven,
ClusterProven or BladeCenter Interoperability Program products. Support for these third-party (non-IBM) products is provided by nonIBM Manufacturers.
•
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does
not give you any license to these patents. Send license inquires, in writing, to IBM Director of Licensing, IBM Corporation, New Castle
Drive, Armonk, NY 10504-1785 USA.