unknown

Container filesystem isolation defaults protect well, but advanced features like bidirectional mount propagation or SELinux relabeling can create host compromise vectors. The kernel auto-demotes shared mounts to MS_SLAVE in less-privileged namespaces, and seccomp blocks mount() by default before AppArmor/SELinux enforcement. OverlayFS kernel bugs (CVE-2023-0386) bypass all container isolation. For untrusted multi-tenant workloads, consider gVisor or Firecracker/Kata instead of relying solely on namespace isolation.

I am breaking my head in Analyzing Container Filesystem Isolation For Multi-Tenant Workloads, so you don’t have to

Evangelos Pappas

I dug into _container filesystem isolation for multi-tenant workloads_—what’s safe by default, and where “advanced” features become footguns. I went syscall-level on mount namespaces, OverlayFS, propagation semantics, SELinux relabeling, seccomp, ...

<p>I dug into _container filesystem isolation for multi-tenant workloads_—what’s safe by default, and where “advanced” features become footguns. I went syscall-level on mount namespaces, OverlayFS, propagation semantics, SELinux relabeling, seccomp, ...</p>