You get industrial grade security solutions out of the box with many Linux distributions. You get namespaces, firewalls and seccomp for free with any Linux kernel, and any Linux system with systemd gets unprivileged containers and sandboxes for free, too. AppArmor exists for MAC, and there are userspace sandboxes.
How many user applications actually fashion a sandbox that is non-trivial to escape with those protections? I struggle to think of any outside of the more popular browsers. The Snap and Flatpak sandboxes are good case studies in the practical limits of Linux sandboxing: it’s rarely effective without designing your entire app around it because the way most applications interact with the system was never designed for it. X11 probably being the most egregious limiter, followed by no standard trusted file access UI.
On the server, there’s a reason Amazon built Firecracker and Google built gVisor instead of just using the Linux sandboxing primitives. I think calling them “industrial grade” is pushing it when they’re rarely used as the first line of defense against code that is expected to be actively hostile.
I agree with the thrust of you comment though, outside the webbrowser, proper sandboxing a barely used outside web browsers. However, I think the problem is as much social as technical. Every time Flatpak comes up, it mostly gets hostile reactions.
The situation is rather unfortunate. A lot of people believe that Linux is more secure than other operating systems, but in practice the Linux desktop is far less secure than e.g. macOS, iOS/iPadOS, or Android.
And no, you aren't safe because it is open source software. Sandboxing also protects against unknown vulnerabilities in open source software.
> On the server, there’s a reason Amazon built Firecracker and Google built gVisor instead of just using the Linux sandboxing primitives.
The reason is that Firecracker is a virtual machine, and Linux containers and sandboxing primitives are not meant to be used for virtual machines.
Pointing at Snap and Flatpak's "sandboxes" is disingenuous when they're notorious for having sandboxing as an after thought to app distribution.
When I say industrial grade, I mean that the sandboxing and isolation primitives that are used in industry are those that are either provided in the kernel, or are deployed as part of a standard Linux server deployment.
Firecracker is a virtual machine that exists to provide a container-level interface. It is not designed for nor capable of running a full virtual machine. GVisor is even less virtual machine like: in fact it originally only worked via a ptrace sandbox and added a KVM-based interface (without a real Linux guest kernel) latter to improve performance.
I point to snap and flatpak because outside of browsers they are AFAICT the only attempts to sandbox user applications on Linux. It would be disingenuous if there were some other apps or distribution channels doing a better job that I hadn’t mentioned, I’d love to hear of some.
> On the server, there’s a reason Amazon built Firecracker and Google built gVisor instead of just using the Linux sandboxing primitives. I think calling them “industrial grade” is pushing it when they’re rarely used as the first line of defense against code that is expected to be actively hostile.
actually firecracker is not a sandbox. it's basically qemu/libvirt and a minimal implementation of devices. it's qemu-kvm with a http interface and way less devices.
the reason why they rewritten qemu-kvm is because qemu-kvm contains a lot of code that is not needed and is way more bug prone. and also loading a kernel is way faster in firecracker since they optimized the kernel loading code.
I’m not sure of the distinction you’re drawing here. Originally Amazon used the Linux namespaces, cgroups, etc. for isolating Lambda invocations, but they only did this at the AWS account granularity (i.e. your Lambdas only shared the same VM with other Lambdas from your account) for security reasons. They built FirecrackerVM so they could run Lambdas freely on the same bare metal machine as others without having to group by tenant VM in this way. Obviously they found using the Linux primitives to be insufficient for maintaining isolation when dealing with hostile native code.
