Towards a VMM-based Usage Control Framework for OS Kernel Integrity Protection Min Xu George Mason University Xuxian Jiang George Mason University Ravi Sandhu University of Texas at San Antonio Xinwen Zhang Samsung Information Systems of America SACMAT 2007
22
Embed
Towards a VMM-based Usage Control Framework for OS Kernel Integrity Protection
Towards a VMM-based Usage Control Framework for OS Kernel Integrity Protection. Xuxian Jiang George Mason University. Min Xu George Mason University. Xinwen Zhang Samsung Information Systems of America. Ravi Sandhu University of Texas at San Antonio. SACMAT 2007. Motivations. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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