02/03/14 Copyright © 2002 WireX Communications, Inc. 1
Autonomix:Autonomic Defenses for Vulnerable Software
Crispin Cowan, Ph.D
WireX Communications, Inc
wirex.com
02/03/14 Copyright © 2002 WireX Communications, Inc. 2
Phase I and Phase II
Phase I: WireX and OGI
WireX: Component Autonomy– Defend software
implementation against common vulnerabilities
OGI: Network and Systemic Autonomy– IDS notification translation– IDS response “orchestrate”
Phase II: Just WireX• More component
Autonomy• LSM: Linux Security
Module
02/03/14 Copyright © 2002 WireX Communications, Inc. 3
AutonomixTechnical Objectives• Tools to guard legacy components against common
software vulnerabilitiesStackGuard: protection from “stack smashing” buffer overflows
SubDomain: lightweight mandatory access controls
FormatGuard: protection from printf format bugs
RaceGuard: protection from temp file races
PointGuard: generalized StackGuard
CryptoMark: kernel-enforced digital signatures for programs
Linux Security Module: facilitate kernel loadable security extensions
Objective: vulnerability tolerance
02/03/14 Copyright © 2002 WireX Communications, Inc. 4
Technical Approach: Abstract
Approach– Local intrusion response– Catch intrusion in process– Halt exploited component
The Canary Technique• Detect attacks in progress:
– Make symptoms of attack mode obvious– Place a sacrificial canary where an attack will show tampering– Monitor canary
• If canary destroyed, then attack is happening
02/03/14 Copyright © 2002 WireX Communications, Inc. 5
Quick Review
• Results previous to this projectStackGuard: protection from “stack smashing” buffer overflows
SubDomain: lightweight mandatory access controls
• Last Year’s Autonomix resultsFormatGuard: protection from printf format bugs
• USENIX Security 2001 paper
• Open source
• In Immunix 7.0 products
RaceGuard: protection from temp file races• USENIX Security 2001 paper
• Didn’t quite make the product cut; in next drop
Relative Invulnerability: empirical measurement of effectiveness of these tools, individually and in combination
02/03/14 Copyright © 2002 WireX Communications, Inc. 6
Major Achievement:Low-Effort Protection • These tools are highly transparent:
– Performance overhead: under 2% across the board, usually lower
– Compatibility issues: minimal• Under 5% of all Linux programs need trivial source patches to
compile with StackGuard and FormatGuard• RaceGuard works on binary code, breaks nothing
– Administrative overhead: nil
02/03/14 Copyright © 2002 WireX Communications, Inc. 7
Proposed Metric:Relative Invulnerability
• Compare a “base” system against a system protected with Immunix tools
• Count the number of known vulnerabilities stopped by the technology
• “Relative Invulnerability”: % of vulnerabilities stopped
02/03/14 Copyright © 2002 WireX Communications, Inc. 8
Immunix Relative Invulnerability• Immunix System 7:
– Based on Red Hat 7.0– Compare Immunix vulnerability to Red Hat’s Errata
page (plus a few they don’t talk about :-)
• October 1, 2000 - May 25, 2001– 57 vulnerabilities total– 16 remote, 41 local– 53 penetration, 4 DoS– 13 remote penetration
02/03/14 Copyright © 2002 WireX Communications, Inc. 9
Immunix Relative Invulnerability
All Penetration RemotePenetration
StackGuard 6/5710%
6/5311%
4/1331%
FormatGuard 6/5710%
6/5311%
2/1315%
RaceGuard 21/5737%
21/5340%
0/130%
*GuardCombination
33/5758%
33/5362%
6/1346%
Server ApplianceConfiguration
28/4070%
28/3678%
5/862%
Server Appliance+ SubDomain
32/4080%
32/3689%
8/8100%
02/03/14 Copyright © 2002 WireX Communications, Inc. 10
New Stuff
• Incremental work:FormatGuard: refinement to improve coverage
RaceGuard: refinement to close hole
• New Autonomix Component TechnologiesPointGuard: generalized StackGuard
CryptoMark: kernel-enforced digital signatures for programs
Linux Security Module: facilitate kernel loadable security extensions
02/03/14 Copyright © 2002 WireX Communications, Inc. 11
New Stuff
• Incremental work:FormatGuard: refinement to improve coverage
RaceGuard: refinement to close hole
• New Autonomix Component TechnologiesPointGuard: generalized StackGuard
CryptoMark: kernel-enforced digital signatures for programs
Linux Security Module: facilitate kernel loadable security extensions
Today’s Focus
02/03/14 Copyright © 2002 WireX Communications, Inc. 12
LSM: Linux Security Module
• Standard Linux kernel limited to classical UNIX security model:– root is everything – POSIX.1e Capabilities
• Linux kernel a common target for security research– Immunix: SubDomain, RaceGuard– Others: SELinux, RSBAC, LIDS, LOMAC, DTE, NAI
Wrappers, Janus, SGI CAPP, etc.
02/03/14 Copyright © 2002 WireX Communications, Inc. 13
LSM: Linux Security Module
• Unfortunately, none are standard to Linux– Maintained as kernel patches– To deploy them, must acquire a custom kernel
• Linus would like to support advanced security policy, but not willing to endorse one project.– Too political… “My security policy is better than yours.”– Linus is not a security expert, and doesn’t want to be– Linux is about choice anyway
• Solution: enrich Linux’s module interface to support security policy modules
02/03/14 Copyright © 2002 WireX Communications, Inc. 14
LSM - Design Goal
• Create a general purpose framework to enable pluggable security modules– Be general enough to support existing security
projects– Work with community to define each project's
needs– Continue to support root/Capabilities, perhaps
as a module
02/03/14 Copyright © 2002 WireX Communications, Inc. 15
LSM Community
• 470 people subscribed to LSM mailing list
• Active participation (code :-) from:– WireX– SELinux (NAI)– SGI– IBM (at least three different locations)– Janus (David Wagner, UC Berkeley)
02/03/14 Copyright © 2002 WireX Communications, Inc. 16
Constrained Design Space
• LSM needs to be:– generic enough for existing security modules– simple enough to be acceptable to the Linux
core maintainers• minimally intrusive patch• easy to understand code
– able to support POSIX.1e capabilities
02/03/14 Copyright © 2002 WireX Communications, Inc. 17
LSM Design
• syscall interposition, i.e. wrappers at the syscall interface– not appropriate: leads to module bloat– already available by re-writing Linux syscall
table
• Instead, we mediate access to internal kernel objects“May subject X access object Y for operation Z?”
02/03/14 Copyright © 2002 WireX Communications, Inc. 18
LSM - Architecture
User-level process
KernelLSMModule
Open syscall•Std. error checks•Std. Security checks•LSM hook:•Complete request
Policy engine•examine context•does request pass policy?•grant or deny
02/03/14 Copyright © 2002 WireX Communications, Inc. 19
LSM - Architecture
User-level process
KernelLSMModule
Open syscall•Std. error checks•Std. Security checks•LSM hook:•Complete request
Policy engine•examine context•does request pass policy?•grant or deny
02/03/14 Copyright © 2002 WireX Communications, Inc. 20
LSM - Architecture
User-level process
KernelLSMModule
Open syscall•Std. error checks•Std. Security checks•LSM hook:•Complete request
Policy engine•examine context•does request pass policy?•grant or deny
“ok with you?”
02/03/14 Copyright © 2002 WireX Communications, Inc. 21
LSM - Architecture
User-level process
KernelLSMModule
Open syscall•Std. error checks•Std. Security checks•LSM hook:•Complete request
Policy engine•examine context•does request pass policy?•grant or deny
“ok with you?”
Yes or no
02/03/14 Copyright © 2002 WireX Communications, Inc. 22
Hook Style
Restrictive: module may only reject a request about to be granted
Permissive: module may only permit a request about to be rejected
Authoritative: module may totally over-rule standard kernel logic
• We chose restrictive hooks only, except for capabilities– Simplifies LSM patch for maximum acceptability to Linux
community
02/03/14 Copyright © 2002 WireX Communications, Inc. 23
Module Stacking
• Strong desire to compose modules• However, composition in general is intractable• Solution: stacking left to modules that want to
stack– Stackable module must export an LSM-like interface
“out the back”– Stackable module responsible for composing policy by
taking down-chain module’s results under advisement
02/03/14 Copyright © 2002 WireX Communications, Inc. 24
Hook Location
Structure ObjectTask_struct Task (process)Linux_binprm ProgramSuper_block FilesystemInode Pipe, File, or SocketFile Open FileSk_buff Network Buffer (Packet)Net_device Network DeviceKern_ipc_perm Semaphore, Shared
Memory Segment, orMessage Queue
Msg_msg Individual Message
02/03/14 Copyright © 2002 WireX Communications, Inc. 25
LSM System Call
• Many modules need a syscall interface for applications to talk directly to the module
• LSM provides a generic syscall interface, and makes the module MUX it– lsm(unsigned int id, unsigned int call, unsigned long *args)
02/03/14 Copyright © 2002 WireX Communications, Inc. 26
Kinds of Hooks
• task hooks
• program loading hooks
• IPC hooks
• FS hooks
• network hooks
• meta-hooks
02/03/14 Copyright © 2002 WireX Communications, Inc. 27
Performance Overhead
• Microbenchmark: lmbench– Tests various critical kernel functions, e.g. open,
read/write, context switch, etc.– Worst case: 7% for trivial calls
• Macro: Khernelstone, i.e. time to make Linux kernel– overhead not measurable– LSM version actually measured faster, but we
don’t claim LSM is an optimization :-)
02/03/14 Copyright © 2002 WireX Communications, Inc. 28
Related Work
• Extensible kernels– Microkernels, SPIN, SCOUT, Synthetix, etc.
• All about safety:– prevent extensions from corrupting the kernel
• Insight: LSM doesn’t need that safety– System is completely at the mercy of security
policy anyway– Go ahead and just trust LSM modules– Use simple dynamic linking technologies
02/03/14 Copyright © 2002 WireX Communications, Inc. 29
Status & Modules
• LSM interface implemented & stable– Linux 2.4.16 and 2.5.1, actively tracking
• Modules:SELinux: NSA & NAI project to add RBAC and
DTE to Linux
DTE: GPL re-implementation of the classic
Openwall: prevents various attacks involving symbolic and hard links
POSIX.1e capabilities
02/03/14 Copyright © 2002 WireX Communications, Inc. 30
OASIS Projects
• SCC: using SELinux via LSM
• Bob Balzer wants to do LSM for Windows
• Wrappers might consider porting to LSM– restrictive hooks may be a problem
• Others?
02/03/14 Copyright © 2002 WireX Communications, Inc. 31
LSM - What's next
• Paper submitted; pending response
• Phase 1:– Submit to Linux 2.5 kernel– Pending on VFS reorg by Linux people
• Phase 2:– Consider extended support for Audit– More permissive hooks beyond Capabilities?– See if Linus is interested
02/03/14 Copyright © 2002 WireX Communications, Inc. 32
Transition of Technology
Open source: StackGuard, FormatGuard, and RaceGuard are all GPL’d
Commercial:– All being incorporated into WireX Server Appliance
products• Server appliance: a server for dummies• Thus the need for dummy-proof security• For sale through eLinux.com, FlexiServe (UK)
– Immunix OS 7.0: hardened Linux distribution• Available for purchase through wirex.com and eLinux.com• Licensed by Counterpane
02/03/14 Copyright © 2002 WireX Communications, Inc. 33
Summary
• Component Autonomy:– Largely working software– Running this laptop: StackGuard, FormatGuard,
RaceGuard, and SubDomain– Available piece wise, or integrated into Immunix OS and
Immunix server appliances, at wirex.com, eLinux.com
02/03/14 Copyright © 2002 WireX Communications, Inc. 34
LSM
• Web site: http://lsm.immunix.org
• Mailing list: on the web site
• BOF at USENIX? USENIX Security?