XPDS16: A Paravirtualized Interface for Socket Syscalls - Dimitri Stiliadis, Aporeto
•
3 recomendaciones•9,031 vistas
Docker and other container runtimes are gathering momentum and becoming the new industry standard for server applications. Linux namespaces, commonly used to run Docker apps, come with a large surface of attack which is difficult to reduce. Intel’s Clear Containers use KVM to run containers as VMs to provide additional isolation. It is possible to provide VM-like isolation for containers without sacrificing performance. This talk focuses on the benefits of using Xen to provide an execution environment for Docker apps. The presentation starts by listing the requirements of this environment. It explains why monitoring container syscalls is important and what its security benefits are. The talk introduces a new paravirtualized protocol to virtualize IP sockets and provides the design and implementation details. The presentation clarifies the impact of the new protocol from a security perspective. The discussion concludes by comparing performance figures with the traditional PV network frontend and backend drivers in Linux, explaining the reasons for any performance gaps.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a XPDS16: A Paravirtualized Interface for Socket Syscalls - Dimitri Stiliadis, Aporeto
Similar a XPDS16: A Paravirtualized Interface for Socket Syscalls - Dimitri Stiliadis, Aporeto (20)
Más de The Linux Foundation
Más de The Linux Foundation (20)
Último
Último (20)
XPDS16: A Paravirtualized Interface for Socket Syscalls - Dimitri Stiliadis, Aporeto
- 2. Overview • Why are we working on this (and what it is not)? • Use cases • Proposed protocol • Performance • Demo
- 4. Security Recommendations (from NCC White Paper) • From “Understanding and Hardening Linux Containers” by NCC Group: • Run unprivileged containers (user namespaces, root capability, dropping) • Apply a Mandatory Access Control system, such as SELinux • Build a custom kernel binary with as few modules as possible • Apply sysctl hardening • Apply disk and storage limits • Control device access and limit resource usage with cgroups • Drop any capabilities which are not required for the application within the container • Use custom mount options to increase defense in depth • Apply GRSecurity and PAX patches to Linux • Reduce Linux attack surface with Seccomp-bpf • Isolate containers based on trust and exposure • Logging, auditing and monitoring is important for container deployment • Use hardware virtualization along application trust zones
- 8. The Alternative: Containers in VMs Kernel Root Ring 0 Ring 3 Container OS Containers Container HypervisorRoot Ring 0 Ring 3 KernelKernel Container Container HW Virtualization Virtual Dev Virtual Dev Virtual Dev Virtual Dev Isolation, significant I/O overheads Different OS between Hypervisor and Guests Device Abstraction Simplicity, limited hardware isolation Same Kernel for all Containers
- 12. System Call Virtualization • Introduce proxy kernel • Same as root kernel • Allows memory pages re-use • Single kernel to manage • Subset of syscallsdelivered to machine kernel • Socket, file , time • Majority of system calls restricted within syscall proxy Syscall Kernel Proxy Root KernelRoot Ring 0 Ring 3 Container Container SyscallVirtualization Unprotected Proxied/Translated Hypercall Syscall Kernel Proxy
- 13. Example Implementation In Xen Dom0App (Container) Xen PV Interface VM Syscall backend Syscall frontend PV Calls All other syscalls Linux DomU internals
- 14. Why Xen? • Efficient para-virtualization interface • Allow deployments in bare metal and cloud • Xen on GCP • (More complex though to do Xen-on-Xen in AWS with para-virtualized IO )
- 15. Example: Network Access • Translate socket calls to hypercalls • Container opens a “paravirtualized socket” inside the host OS • Uses natively IP stack of host • Security and forwarding policies applied at the host Syscall Kernel Proxy KernelRoot Ring 0 Ring 3 Container Container SyscallVirtualization Syscall Kernel Proxy Connect Connect 10.1.1.5 NIC 10.1.1.5
- 16. Example: Network Access with Namespaces • Container namespace created at the host as before • Container process is launched inside a protected VM • Through System Call virtualization system calls applied to namespace context • Container gets IP address of network namespace • Transparent to Docker and other container systems Syscall Kernel Proxy Root Ring 0 Ring 3 Container Container SyscallVirtualization Syscall Kernel Proxy Connect Connect 192.168.2.1 Bridge 192.168.2.1
- 18. First Implementation • Design document • http://marc.info/?l=xen-devel&m=147033114613017 • Code • First, simple implementation on Xen • 1 Command ring • Per socket: • data ring • event ring • Variable ring data sizes configurable per socket • Supported functions (socket, connect, release, bind, listen, accept, poll) • git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-5
- 20. App (Container) Linux DomU Xen POSIX PV Interface VM Dom0 Iperf -c 127.0.0.1 Iperf -s PV Calls
- 21. PV Calls
- 22. App (Container) Linux DomU Xen POSIX PV Interface VM Dom0 Iperf -s Iperf -c 127.0.0.1 PV Calls
- 23. PV Calls
- 24. ?! PV Calls
- 27. PV Calls
- 28. And , you use something like that today (Docker for Mac and VPNKit) Mac OSx Root Ring 0 Ring 3 Kernel Docker for Mac Virtual Dev Virtual Dev Virtual Dev The “simplistic” version of the syscall proxy Socket Proxy Container Container “VPNKit operates by reconstructing Ethernet traffic from the VM and translating it into the relevant socket API calls on OSX or Windows. This allows the host application to generate traffic without requiring low-level Ethernet bridging support.”
- 29. First Implementation • Design document • http://marc.info/?l=xen-devel&m=147033114613017 • Code • First, simple implementation on Xen • 1 Command ring • Per socket: • data ring • event ring • Variable ring data sizes configurable per socket • Supported functions (socket, connect, release, bind, listen, accept, poll) • git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-5
- 30. Extensions • Mechanism is generic and can be extended to other system calls • Co-processing of system calls is also possible • Guest can process system call parameters and translate at hypercall • Resolve memory references (pointers) • Resolves TOCTOU risk of system call interposition • Time of Check/Time of Use • Using N/N+1 kernel versions can reduce attack surface farther
- 31. Demo 1: Performance Comparison Kernel Root Ring 0 Ring 3 Container Syscall Proxy KernelRoot Ring 0 Ring 3 Container Container SyscallVirtualization Syscall Proxy Container No noticeable performance difference
- 32. Demo 2: Kernel Exploit Kernel Root Ring 0 Ring 3 Container Docker Container Vulnerable container crashes machine and all other containers Syscall Proxy KernelRoot Ring 0 Ring 3 Container Container SyscallVirtualization Syscall Proxy Vulnerable container crashes itself only Attack contained