Comment on Virtual Machines vs LXC vs Docker: What’s the Real Difference?
Neptr@lemmy.blahaj.zone 2 days ago
In order of most to least secure
VM > Docker+GVisor > Docker/LXC
Docker+GVisor is good middle ground because it provides the guest container with an application kernel in a memory safe language and reduced syscall attack surface to avoid kernel container escapes. Docker/LXC share the kernel with the host.
non_burglar@lemmy.world 2 days ago
Subjective to security practice. There are more appropriate factors than blanket statements on a technology’s inherent “security” when deciding the format and shape of virtual software spaces.
Ultimately, the implementation is more important than the underlying code when it comes to containers. cgroups2 works the same for gvisor as it does for LXC.
Neptr@lemmy.blahaj.zone 2 days ago
I dont really understand what you mean in your last sentence.
My reason for saying GVisor is safer is because it is an application kernel which provides traps and emulates most Linux syscalls in the guest with a far smaller set of syscalls to the host kernel, helping to prevent container escapes and privilege escalation. GVisor also fully drops privileges early into start up (before running any significant logic), helping to prevent privilege escalation.
Cgroups is not a really a security feature (from what I understand). It is about controlling process priority, hierarchy, and resources limiting (among other things). You can not use GVisor with LXC.
non_burglar@lemmy.world 2 days ago
With respect, I think you misunderstand what gvisor does and containerization in general. cgroups2 is the isolation mechanism used by most modern Linux containers, including docker and lxc both. It is similar to the jail concept in BSD, and loosely to chroot. It limits child process access to files, devices, memory, and is the basis for how subprocesses are secured against accessing host resources without the permission to do so.
Gvisor adds more layers of control over this system by adding a syscall control plane to prevent a container from accessing functions in the host’s kernel that might not be protected by cgroups2 policy. This lessens the security risk of the host running a cutting-edge or custom kernel with more predictable results, but it comes with caveats.
Gvisor is not a universally “better” option, especially for homelab, where environment workloads vary a lot. Gvisor comes with an IO performance penalty, incompatibility with selinux, and its very strength can prevent containers from accessing newer syscalls on a cutting edge host kernel.
My original comment was that ultimately, there is no blanket answer for “how secure is my virtualization stack”, because such a decision should be made on a case-by-case basis. And any choice made by a homelabber or anyone else should involve some understanding of the differences between each type.
Neptr@lemmy.blahaj.zone 1 day ago
Yes, I understand what GVisor does. Cgroups2 are for isolation of system resources, bit arent even the main sandbox feature used for isolation by Docker. I am pretty sure namespaces significantly more important for these containers’ security.
GVisor helps with one of the main risks in a container setup which is the shared kernel by hosts and guests. I understand it comes with a performance penalty (and I didnt know it was incompatible with SELinux), but that does change my original point that GVisor is a security improvement to default Docker. I understand there is more nuance, even when I wrote my original comment I understood (just like any other security feature) it cant be used in every scenario. I was being intentionally general, and in my second comment I was pretty specific about what it protects against: Kernel vulnerabilities and privilege escalation.
I researched cgroups2 more and I still dont understand why you brought it up in the first place. Cgroups2 and gvisor provide very different security benefits. Cgroups help to keep a system available (lessening the risk DoS attacks) by controlling access to some system resources (io, devices, cpu, memory) and grouping processes of a similar type. It seems rather optimized to solve resource control on a container host. I mentioned gvisor because it is mostly just a drop-in replacement container runtime which doesnt need setup to be used.s
Now for a different container runtime which provides significantly more features (than gvisor) with less downsides (if configured correctly for a specific workload), Sydbox provides syd-oci which id an application kernel runtime which uses a permission config file to create a sandbox, isolating using namespaces, seccomp, landlock, and more. It can sandbox in many different categories (often times leveraging multiple features to provide a multilayer sandbox), you can see the categories at the syd manpage. The biggest downside is that you must really understand what your container application needs otherwise it will prevent it from running. It is a “secure by-default” sandbox which can be softened through config.