Security at the VMM Layer

Theodore WinogradOWASP

June 14, 2007

Outline

Why? VMM Selection Syslog Capture Simple MAC via sys_open Simple MAC via LSM Future Work

Why at the VMM layer?

COTS software is notoriously buggy

We still have to use it Isolate it—and protect the VM

system at the same time

Why at the VMM layer?

Honeypots require fine-grained access control

We can’t trust anything on a honeypot

VMM Selection

QEMU Little documentation Unstable Logging is

too detailed Code difficult to

follow

Ideal for security VMM

UML Little documentation Kernel code

documented arch/um/include/os.h

os_open_file os_read_file os_write_file os_close_file

Logging Capture

Audit logs must maintain integrity Logs may be recorded at:

HW – VM Introspection OS – OS service API – API hooking Application – syslog, log4j, etc…

Each layer loses integrity

Syslog Capture

Why? Most Linux applications use syslog Improve the integrity of the logs

Why not via the network? Attackers could modify the syslog daemon Would require network access to the host

This could be implemented for any logging framework

Syslog Capture:Syslog Architecture

util-linux – logger.c UNIX datagram sockets

glibc – syslog.h and syslog.c /dev/log

Sample contents:

<38>Mar 25 22:05:09 login[1890]: ROOT_LOGIN on `tty0’

Capture Options

net/socket.c Capture ALL socket data sys_send* function calls

net/unix/af_unix.c unix_dgram_connect unix_dgram_sendmsg

unix_dgram_connect unix_dgram_sendmsg Both receive struct sockaddr *

Same address Only connect receives the path name

Capture Functions

sockaddr * list Store a list of sockaddr * pointers Add to the list at unix_dgram_connect Compare unix_dgram_sendmsg to the

list Remove at unix_release

MAC

Enforces Bell-LaPadula security model No write-down No read-up

Enforces process separation Red Hat’s SELinux targeted policies

Simple MAC via sys_open

Why? Prevent malicious code from accessing

sensitive portions of the system Prevent information leakage Maintain file integrity External policy file sys_open is easy to intercept One step towards LSM-based approach

Access Control File Format

+/-[rwa]:file:UID

-r:/tmp/log:1000

-r:/tmp/log:0

+w:/tmp/log:0

Linux kernel: do_sys_open

long do_sys_open( int dfd, const char __user *filename, int flags, int mode)

MAC For every open, compare filename,

flags, and uid against the access file current macro – process descriptor

UID, PID, GID, parent, etc… Flags

…00 – read-only …01 – write-only …10 – read-write …11 - special

sys_open problem

filename can be relative current->fs knows the

current working directory Allows for an easy bypass

Must find equivalent inode

Simple MAC via LSM

Linux Security Modules NSA SELinux

Why? External policy Access control for OSs without MAC No need to configure the existing OS

Access Control

Same access file as sys_open MAC Map filename to an inode Compare inodes

LSM Hooks

security/selinux/hooks.c selinux_file*

security/dummy.c dummy_file*

Demonstration

Future Work Code hooks to external LSM modules QEMU implementation

Log capture and MAC for other OSs

Related work: “A VM Introspection Based Architecture for Intrusion Detection”

T. Garfinkel: http://suif.stanford.edu/papers/vmi-ndss03.pdf

“Towards a VMM-based Usage Control Framework for OS Kernel Integrity Protection”X. Jiang: http://www.ise.gmu.edu/~xjiang/pubs/SACMAT07.pdf

Questions?winograd_theodore@bah.com