3 ms·
Wow, how did I not know about this! Unless I'm missing something, the limitations mentioned in the docs don't seem too limiting. Is there anything that needs t
by GordonS 5y ago
Wow, how did I not know about this!
Unless I'm missing something, the limitations mentioned in the docs don't seem too limiting. Is there anything that needs to be changed or watched out for in real life?
- foresto 5y agoIt requires a kernel that allows unprivileged user namespaces. Docker images that run as uid 0, which many of them do, could potentially exploit their way out of the container, since kernel code running as (actual or namespaced) uid 0 hasn't been extensively tested to be safe and bug-free. You might have to experiment with different "drivers" to get the overlay filesystem and cgroups components to work on any given host. (These are not hardware drivers, but something more like docker subsystem plugins.) By default, it expects a dbus user session, which a headless server might not have. You can either enable one or configure a different `cgroupdriver`.
- staticassertion 5y agoTBH the Linux kernel isn't capable of providing an isolation boundary anyways, so while it's a meaningful regression if your assumption is "attacker in the container" I highly recommend using gVisor or Firecracker, or otherwise reducing the need to trust the Linux kernel for anything like resisting hostile local attackers.