The document discusses the security comparisons between containers and virtual machines, citing varying expert opinions on their relative safety and vulnerabilities. It highlights the ongoing debate about the security of virtualization layers and contains specific examples of known vulnerabilities in Xen, KVM, QEMU, and Linux. The overarching theme emphasizes the importance of configuration and the potential for mistakes in security management across all systems.

1. Security in the Cloud:
Xen, KVM, Containers
Or, Surviving and the Zombie Apocalypse

2. “Some people make the mistake of thinking of containers as a
better and faster way of running virtual machines. From a security
point of view, containers are much weaker.”
–Dan Walsh (Mr. SELinux)

3. “There's contentions all over the place that containers are not
actually as secure as hypervisors. This is not really true. Parallels
and Virtuozo, we've been running secure containers for at least 10
years.”
–James Bottomley, Linux Maintainer and Parallels CTO

4. “Virtual Machines might be more secure today, but containers are
definitely catching up.”
–Jerome Petazzoni, Senior Software Engineer at Docker

5. “You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write
operating systems or applications without security holes, can then
turn around and suddenly write virtualization layers without
security holes.”
–Theo de Raadt, OpenBSD project lead

6. "Some people make the mistake of thinking of containers as a better and faster
way of running virtual machines. From a security point of view, containers are
much weaker." -Dan Walsh
"There's contentions all over the place that containers are not actually as secure
as hypervisors. This is not really true. Parallels and Virtuozo, we've been running
secure containers for at least 10 years.” -James Bottomley
"Virtual Machines might be more secure today, but containers are definitely
catching up." -Jerome Petazzoni
"You are absolutely deluded, if not stupid, if you think that a worldwide collection
of software engineers who can't write operating systems or applications without
security holes, can then turn around and suddenly write virtualization layers
without security holes." -Theo de Raadt

7. Who am I?

8. What I’m going to talk about

9. Security and Risk

10. Vulnerabilities and Exploits

11. A vulnerability is a mistake.

12. Configuration vulnerabilities

13. Software vulnerabilities

16. Intel SYSRET

17. Zombie Apocalypse.

23. Every window is an opportunity
to make a mistake

24. Every element of every interface is
an opportunity to make a mistake

25. But does this really matter?

27. Would this affect a system
configured reasonably for security?

28. Xen: Access to HV memory
>5TiB during migration

29. Xen: Unsecured PV console
parameters

30. Xen: 1 year, 1-4 known
vulnerabilities

31. KVM: Escalation in vhost

32. KVM: PUSHA instruction
emulation

33. KVM: vcpu hypercall boundary
check

34. KVM: vlapic shared page
crossing a page boundary

35. KVM: 1 year, 4 solid
vulnerabilities

36. qemu: VMWare emulated device

37. qemu: virtio-net mac address
update

38. qemu: 1 year, 2 known
vulnerabilities

39. Linux: ping

40. Linux: tty race condition

41. Linux: ptrace and SYSRET

42. Linux: AIO, arbitrary read of
kernel memory

43. Linux: Futex not checking if two
pointers were different (2)

44. Linux: AMD math coprocessor

45. Linux: 2 months, 6 vulnerabilities

46. Hypervisors:
Low (but not zero) risk

47. General-purpose containers:
Not so good

48. Application-specific containers
+ seccomp2?

50. Questions?