Towards a VMMbased Usage Control Framework for OS Kernel Integrity Protection

1
Towards a VMM-based Usage Control Framework for
OS Kernel Integrity Protection

• Min Xu
• George Mason University

Xuxian Jiang George Mason University
Xinwen Zhang Samsung Information Systems of
America
Ravi Sandhu University of Texas at San Antonio
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 computerRootkitsSubeverting 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
• UCONKI model for OS kernel integrity
• Event-based logic model for UCONKI policy
  specification
• VMM-based Enforcement Architecture
• Prototype
• Evaluation
• Conclusion and Future Work

7
UCON Model (Park and Sandhu 2004)

• Attributes can be updated as side-effects of a
  usage
• pre, ongoing, and post updates
• Persistent and mutable attributes
• Attribute Mutability

8
UCONKI 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 UCONKI

• A UCONKI policy is a well-typed policy rule of
  the form
• (e1 ? ? ei) causes (act1? ? actj) if
  (p1 ? ? pk) where e1 ,, ei are events, act1 ,,
  actj are actions, and p1 ,, pk are predicates.
• A UCONKI policy specifies that when events e1
  ,, ei occur, actions act1 ,, actj must be
  performed by the system if predicates p1 ,, pk
  are satisfied.

10
Subjects events and system actions
means repetition
11
Example Policies specified by EPA

• Pre-Authorization
• Mutability

12
Architecture
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)

14
Architecture

• 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
  objects 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

Interesting symbols found from /boot/system.map
16
Prototype
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

• UCONKI 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

22

• Thank You!
• Email mxu_at_gmu.edu
• URL http//www.list.gmu.edu/mxu