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

1. 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

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: • 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. Three phases of a usage process • Decision in first two phases • pre-decision • ongoing-decisions: repeatedly check during ongoing usage phase • Decision Continuity 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 ,…, actjmust 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 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 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@gmu.edu URL: http://www.list.gmu.edu/mxu