1. Security at the VMM Layer Theodore Winograd OWASP June 14, 2007

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

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

4. Why at the VMM layer? Honeypots require fine-grained access control We can’t trust anything on a honeypot

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

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

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

8. Syslog Capture: Syslog Architecture util-linux – logger.c UNIX datagram sockets glibc – syslog.h and syslog.c /dev/log Sample contents: Mar 25 22:05:09 login[1890]: ROOT_LOGIN on `tty0’

9. Capture Options net/socket.c Capture ALL socket data sys_send * function calls net/unix/af_unix.c unix_dgram_connect unix_dgram_sendmsg

10. unix_dgram_connect unix_dgram_sendmsg Both receive struct sockaddr * Same address Only connect receives the path name Capture Functions

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

12. MAC Enforces Bell-LaPadula security model No write-down No read-up Enforces process separation Red Hat’s SELinux targeted policies

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

14. Access Control File Format +/-[rwa]:file:UID -r:/tmp/log:1000 -r:/tmp/log:0 +w:/tmp/log:0

15. Linux kernel: do_sys_open long do_sys_open( int dfd, const char __user *filename, int flags, int mode )

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

17. sys_open problem filename can be relative current->fs knows the current working directory Allows for an easy bypass Must find equivalent inode

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

19. Access Control Same access file as sys_open MAC Map filename to an inode Compare inodes

20. LSM Hooks security/selinux/hooks.c selinux_file* security/dummy.c dummy_file*

21. Demonstration

25. 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.pdfhttp://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.pdfhttp://www.ise.gmu.edu/~xjiang/pubs/SACMAT07.pdf

26. Questions? winograd_theodore@bah.com