Security at the VMM Layer

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 itand protect the VM system at the same
  time

4
Why at the VMM layer?

• Honeypots require fine-grained access control
• We cant 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 CaptureSyslog Architecture

• util-linux logger.c
• UNIX datagram sockets
• glibc syslog.h and syslog.c
• /dev/log
• Sample contents
• lt38gtMar 25 220509 login1890 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
Capture Functions

• unix_dgram_connect
• unix_dgram_sendmsg
• Both receive struct sockaddr
• Same address
• Only connect receives the path name

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

• /-rwafileUID
• -r/tmp/log1000
• -r/tmp/log0
• w/tmp/log0

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-gtfs 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
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
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 DetectionT. Garfinkel
  http//suif.stanford.edu/papers/vmi-ndss03.pdf
• Towards a VMM-based Usage Control Framework for
  OS Kernel Integrity ProtectionX. Jiang
  http//www.ise.gmu.edu/xjiang/pubs/SACMAT07.pdf

26
Questions?
winograd_theodore_at_bah.com