towards a vmm-based usage control framework for os kernel integrity protection min xu george mason...
TRANSCRIPT
Towards a VMM-based Usage Control Framework for OS Kernel Integrity
Protection
Min XuGeorge Mason
University
Xuxian JiangGeorge Mason
University
Ravi SandhuUniversity of Texas at
San Antonio
Xinwen ZhangSamsung Information Systems of America
SACMAT 2007
2
Motivations Ensuring the integrity of kernel resources is a
fundamental goal of OS security Exploiting a vulnerability allows the attacker to
modify the kernel and core system utilities, hence compromising the integrity of the entire system
Malware: Worms, Keyloggers, Rootkits …
3
Threat Example: Rootkits “A rootkit is a set of programs and code that
allows a permanent or consistent, undetectable presence on a computer”—Rootkits:Subeverting the Windows Kernel
Goals: Hide malicious resources (e.g., processes, files, registry keys,
open ports, etc.) Provide hidden backdoor access
Techniques: modifying kernel resources (integrity violation)
Loadable Kernel Modules (most popular method) Modify system call table, kernel text, Interrupt Descriptor Table
(IDT) Patching the running kernel (memory modification)
Modify /dev/kmem
4
Existing Approaches Existing Models: MAC (Biba, Bell-LaPadula, Chinese
Wall) Clear goal Too restrictive, coarse-grained No ongoing check
Existing Enforcement Mechanisms: User-Level
Good performance No isolation Easily compromised
OS Kernel (SELinux) No isolation Too many polices (50,000 +policies in Linux 2.6.18)
Hardware-based Coprocessor (Copliot) Isolation Needing another PCI card, no real time prevention
5
Our Approach Virtual Machine Monitor (VMM) based
Architecture Strong Isolation: Compromised guest OS cannot
disable protection mechanism in VMM Introspection: VMM can see hardware states Interposition: VMM can enforce memory access, NIC …
VMM can monitor and enforce events happening in a guest VM.
UCON Decision continuity and attribute mutability Previous work has shown policy specification flexibility
of UCON
6
Outline Policy and Model:
UCONKIKI model for OS kernel integrity Event-based logic model for UCONKIKI
policy specification VMM-based Enforcement Architecture Prototype Evaluation Conclusion and Future Work
7
UCON Model (Park and Sandhu 2004)
Rights(R)
Authorizations
(A)
Subjects(S)
Objects(O)
Subject Attributes (SA) Object Attributes (OA)
Obligations(B)
Conditions(C)
UsageDecisions
Attributes can be updated as side-effects of a usage: pre, ongoing, and post updates Persistent and mutable attributes Attribute Mutability
before usage ongoing usage after usage
Continuity ofDecisions
pre-decision ongoing-decisions
pre-updates ongoing updates post-updates
Mutability ofAttributes
Three phases of a usage process Decision in first two phases
pre-decision ongoing-decisions: repeatedly check during ongoing usage phase
Decision Continuity
8
UCONKI KI Model for OS Kernel Integrity Subjects (S):
Active processes and loadable kernel modules (LKMs) Objects (O):
Kernel memory spaces, disk devices, and registers Subject attributes (ATT(S)):
Text hash values of subjects Object attributes (ATT (O)):
Addresses, types, status of objects Rights (ATT (R)):
Generic actions such as read and write Authorizations:
Functional predicates that have to be evaluated for usage decisions
9
Event-based Policy Model for UCONKIKI
A UCONKI KI policy is a well-typed policy rule of the form:
(e11 … eii) causes (act11… actjj) if (p11 … pkk) where e11 ,…, eii are events, act11 ,…, actjj are actions, and p11 ,…, pk k are predicates.
A UCONKI KI policy specifies that when events e11 ,…, eii occur, actions act11 ,…, actjj must be performed by the system if predicates p11 ,…, pk k are satisfied.
10
Subjects events and system actions
Before Usage After
revokeaccess postupdate
endaccess
preupdate onupdate*permitaccess
ordenyaccess
System Actions
Subject Events
tryaccess ongoingaccess*
* means repetition
11
Example Policies specified by EPA Pre-Authorization
Mutability
12
Architecture
AttributesRepository(AR)
Polic
y D
ecis
ion
Poin
t(PD
P)
1
Gue
st V
M
Hos
t OS
with
VM
ME
xten
sion
Polic
y D
atab
ase
2Access VectorCache(AVC)
6
6
VM Enforcer
7
3 4
5
89
10 11
Kernel
Proces1 Process2Systemobjects
13
Architecture Subject generates an access
request event from the guest VM and intercepted by VME (step 1)
VME contacts AR and retrieves the subjects and objects attributes (steps 2 and 3)
VME queries AVC (step 4)
If AVC has valid entry and S & O attributes not changed, gives yes (step 5) and goes to step 8, otherwise gives no and goes to step6
VME pushes S & O attributes to PDP (step 6)
PDP makes access control decision according to policy and S & O attributes (step 7)
The decision is forwarded to VME and enforced in the VM (step 8)
AttributesRepository(AR)
Po
licy D
ecis
ion
Po
int(
PD
P)
1
Gue
st V
M
Host
OS
with
VM
MExt
ension
Po
licy D
ata
ba
se
2Access VectorCache(AVC)
6
6
VM Enforcer
7
3 4
5
8
Kernel
Proces1 Process2Systemobjects
14
Architecture
AttributesRepository(AR)
Po
licy D
ecis
ion
Po
int(
PD
P)
Gues
t VM
Hos
t OS
with
VMM
Exten
sion
Po
licy D
ata
ba
se
Access VectorCache(AVC)
VM Enforcer
9
10 11
Kernel
Proces1 Process2Systemobjects
Update of attributes (Mutability)
VME gets the new attributes
from the guest VM (step 9) New subject/object
attributes are pushed back to AR (step 10)
e.g. update system call table address after legitimate process modified it
Update the decision cache VME pushes the decision
along with subject and object’s attributes to AVC after usage (step11)
15
Prototype Implementation An OS kernel integrity
protection system Bochs IA-32 Emulator Guest VM: Red hat7.2
(Linux 2.4.7-10) Example policy: kernel
text, system call table, IDT table and virtual file system dispatch table cannot be modified
Symbol Use
_text_etext_sys_call_tableidt_tabeproc_root_operations
Beginning of kernel textEnd of kernel textsystem call tableInterrupt Descriptor TableRoot File System Ops
Interesting symbols found from /boot/system.map
16
Prototype
Kernel Text
System call table
Interrupt DescriptionTable
Virtual file system
proc_root_ops
root_dir_ops
0xc00000000
0xc0100000
0xc023d600
0xc023e13c
0xc023e53c
0xc028f000
0xc028f800
0xc0241d20
0xd0838560
0xfe0000000
sys_exit sys_fork sys_read sys_write sys_execve …
Runtime addresses collected from a Redhat 7.2 Linux system (2.4.7-10)
17
Evaluation Evaluation results with 18 real-world kernel rootkits
18
Example Rootkits
“Adore” rootkit
“Adore-ng” rootkit
“suckit” rootkit
19
Possible Extensions
UCONKIKI Extensions Attributes Management Conditions Obligations
Policy Enforcement
20
Conclusions We have proposed a VMM-based
usage framework for OS kernel integrity protection
We have subjected our prototype to 18 real-world kernel rootkits to validate its practicality and effectiveness
21
Ongoing and Future Work Extending our framework for
general OS security Porting to other VMM platforms,
like XEN
