Security-enhanced Linux: Bringing Secure Operating System Research to the Open Source Arena
Peter A. Loscocco
loscocco@tycho.nsa.gov
Information Assurance Research Group
National Security Agency
Presentation Outline
Operating system security
Security-enhanced Linux
Using Open Source
Operating System Security
Why secure the OS?
Increasing risk to valuable information
Information attacks don’t require a corrupt user
Applications can be circumvented
Must process in the clear
Network too far/Hardware too close
Secure system requires secure OS
Irrefutable
Well understood for many years
Reflected in existing criteria
Need for Secure OS
Dependence on OS protection mechanisms
Inadequacy of mainstream operating systems
Key missing feature: Mandatory Access Control (MAC)
Administratively-set security policy
Control over all subjects and objects in system
Decisions based on all security-relevant information
Barriers
Concerns of feasibility and universality of need
Why is DAC inadequate?
Decisions are only based on user identity and ownership
No protection against malicious software
Each user has complete discretion over his objects
Only two major categories of users: superuser and other
Many system services and privileged programs must run with coarse-grained privileges if not as superuser
What can MAC offer?
Strong separation of security domains
System, application, and data integrity
Ability to limit program privileges
Protection against tamper and bypass
Processing pipelines guarantees
Authorization limits for legitimate users
MAC Implementation Issues
Must overcome limitations of traditional implementations
More than just Multilevel Security
Address integrity, least privilege, separation of duty issues
Complete control using needed security relevant information
Control relationships between subjects and code
Policy flexibility required
One size does not fit all!
Ability to change the model of security
Ability to express different policies within given model
Separation of policy from enforcement
Maximize security transparency
Customize according to need
Separation policies
Establishing Legal Restrictions on data
Restrictions to classified/compartmented data
Confinement policies
Restricting web server access to authorized data
Minimizing damage from viruses and other malicious code
Integrity policies
Protecting applications from modification
Preventing unauthorized modifications of databases
Invocation policies
Guaranteeing that data is processed as required
Enforcing encryption policies
Security Solutions with Flexible MAC
Confines malicious code
Can safely run code of uncertain pedigree
Constrains code inserted via buffer overflow attacks
Limits virus propagation
Allows effective decomposition of root
Root no longer all powerful
Limits each root function to needed privilege
Eliminates most privilege elevation attacks
Allows effective assignment of privilege
Servers need not run with complete access
Servers and needed resources can be isolated
Separate protections for system logs
Toward a New Form of MAC
Research by NSA with help from SCC
Generalized from prior Type Enforcement work
Provide flexible support for security policies
Cleanly separate policy from enforcement
Address limitations of traditional MAC
DTMach, DTOS, Flask
SELinux is application of Flask Security Architecture
The Flask Security Architecture
Cleanly separates policy from enforcement.
Well-defined policy interfaces.
Support for policy changes.
Allows users to express policies naturally.
Fine-grained controls over kernel services.
Caching to minimize performance overhead.
Transparent to applications and users.
The Flask Security Architecture
Policy Decisions/Changes
Making policy Decisions
Labeling: Obtaining a label for a new subject or object.
Access: Determining whether a service on an object should be granted
Supporting policy changes
Interfaces for policy changes
Revalidation of permissions on use
Controlled Services
Permissions are defined on objects and grouped together into object classes
Examples
Process: code execution, transitions, entrypoints, signals, wait, ptrace, capabilities, etc.
File: fd inheritance and transfer, accesses to files, directories, file systems
Socket: accesses to sockets, messages, network interfaces, hosts
System V IPC: accesses to semaphores, message queues, shared memory
Security: accesses to security server services
API Enhancements
Existing Linux API calls unchanged
Linux applications run unchanged!
New API calls for security-aware applications
New API calls for application policy enforcers
SELinux Security Server
Implements combination of Role-Based Access Control, Type Enforcement, optional Multi-Level Security
Labeling and access decisions defined through set of configuration files
Example policy configuration provided
Example Policy Configuration: TE Concepts
Domains for processes, types for objects.
Specifies allowable accesses by domains to types.
Specifies allowable interactions among domains.
Specifies allowable and automatic domain transitions.
Specifies entrypoint and code execution restrictions for domains.
Type Enforcement: Domains
Type Enforcement: Types
Example Policy Configuration: RBAC concepts
Roles for processes
Specifies domains that can be entered by each role
Specifies roles that are authorized for each user
Initial domain associated with each user role
Role transitions are typically explicit, e.g. login or newrole
Role-Based Access Control: Roles
Example Policy Configuration: Security Objectives
Protect kernel integrity, including boot files, kernel modules, sysctl variables
Protect integrity of system software, configuration files, and logs
Protect administrator role and domain
Confine system processes and privileged programs
Protect against execution of malicious software
Linux Security Module Project
Goal is to develop common set of kernel hooks to allow security LKMs to be defined
Hosted by WireX - http://lsm.immunix.com
Patches to 2.5.x kernel ready for submission to kernel developers
SELinux LKM using LSM
Available at http://www.nsa.gov/selinux
Also included with LSM
Path for SELinux with mainstream Linux
SELinux Research
Complete integration into networked environment
Policy specification and analysis
Platform for application security mechanisms
SELinux Success
Corporate interest
Pursuing SELinux based products/solutions
OS Distributor interest
SELinux Debian package
Contacts from major distributors
SELinux deployments
Corporate, government, universities
SELinux Success (Cont.)
Community interest
Mailing list >800 members
Continued positive press attention
Many requested SELinux presentations
SELinux ideas being applied to Free BSD
Decision to move to Open Source
Recognized need to move to a mainstream platform
Past strategies not producing desired results
National Security Council interest in Open Source
Technology transfer opportunities
Linux chosen as best alternative
Open Source Code Environment
Broad category of software made available under public license
Shared source code/community review
Open development environment, peer design
Acceptance based on technical merit
Diverse application types
Operating Systems (Linux Kernel)
Domain name system (DNS/BIND)
e-mail transport agents (sendmail)
Scripting languages (Perl)
Open Source Security
Security benefits
Wide review
Rapid patching
Variability and user customization possible
Non-proprietary testing
Security drawbacks
Adversary analysis
Local variations can lead to vulnerabilities
Easier to insert malicious code
Variants make malicious code harder to spot
Open analysis not necessarily more rigorous
OSC for Technology Transfer
Share results freely
Not tied to business plans of single vendor
Leverage off large developer community
Results applicable to other OS
Direct user impact
Showcase expertise
Valuable contributor
Recruiting
Open Source for Fed. Gov.
Research alternative
Excellent technology transfer vehicle
Increased opportunities for business contacts
Excellent partnership opportunities
Low cost access to products/technical information
Consumer of Open Source products
Wide variety of products at no cost
Site customizations possible
Growing support industry
Certification/accreditation still a stumbling block
Issues for Fed. Gov.
Licensing issues
GPL vs. BSD-style or something different
Can gov software even be licensed?
Contracting issues
Contracting law vs. Government intellectual property
Contracting law vs. full participation in Open Source arena
Web server issues
Software release on server is not business as usual
Support of mailing list and archives
Incorporating contributions of others
Lessons
Expect pitfalls at every turn
Some real
Some manufactured because of misconceptions
Educate your management
Once understood, our goals were supported
Get to know your legal staff
They can keep you out of trouble
They can find ways to help navigate the pitfalls
Legal issues related to open source being discussed throughout government
Questions?
SELinux Available at: http://www.nsa.gov/selinux
Mailing list: Send ‘subscribe selinux’ to majordomo@tycho.nsa.gov
email: loscocco@tycho.nsa.gov