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

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 computerRootkits: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 ) 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: KI UCON KI model for OS kernel integrity KI Event-based logic model for UCON KI 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 Three phases of a usage process Decision in first two phases pre-decision ongoing-decisions: repeatedly check during ongoing usage phase Decision Continuity

8 KI UCON 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 KI Event-based Policy Model for UCON KI KI A UCON KI policy is a well-typed policy rule of the form: 1i1j1k 1i1j 1k (e 1 … e i ) causes (act 1 … act j ) if (p 1 … p k ) where e 1,…, e i are events, act 1,…, act j are actions, and p 1,…, p k are predicates. KI 1 i1j 1k A UCON KI policy specifies that when events e 1,…, e i occur, actions act 1,…, act j must be performed by the system if predicates p 1,…, p k 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 ) Example policy: kernel text, system call table, IDT table and virtual file system dispatch table cannot be modified SymbolUse _text _etext _sys_call_table idt_tabe proc_root_opera tions Beginning of kernel text End of kernel text system call table Interrupt Descriptor Table Root File System Ops Interesting symbols found from /boot/system.map

16 Prototype sys_exit sys_fork sys_read sys_write sys_execve … Runtime addresses collected from a Redhat 7.2 Linux system ( )

17 Evaluation Evaluation results with 18 real-world kernel rootkits

18 Example Rootkits Adore rootkit Adore-ng rootkit suckit rootkit

19 Possible Extensions KI UCON KI 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

Thank You! URL: