An informative YT channel I found. I’m sure many people here might already know, but I found it helpful and it makes the comm a good resource for newer folks looking to get a handle on what all these tools do and how they will use them in their selfhosting.
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.
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.