View
217
Download
0
Tags:
Embed Size (px)
Citation preview
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