Not really. Generally we use "Local Privilege Exploit" to describe an exploit that goes from a reasonably normal user privileges to root privileges.
And we don't usually worry about them, because an application with normal user privileges can already to so much damage.
But this exploit can be triggered from inside a tightly sandboxed process, such as firefox's isolated browser process. Which means the attacker now only needs to chain two exploits together: One javascript exploit to get local code execution in an isolated sandbox, and this one to jump all the rest of the way to kernel mode.
Which means, you should update both firefox, and your linux kernel.
Realistically, if you have a browser sandbox, the system LPE exploit gives you very little more. Everything interesting on a desktop system is accessible by the user account directly.
They are a security boundary. The fact that you need a vulnerability to escape them is proof of that. They just don't have a particularly high cost of escape because reachable kernel vulnerabilities are so common.
If you are given a shell with `docker run -it --rm alpine:3 sh`, can you read the /etc/shadow on the host without kernel exploit? Assuming the docker and kernel are sufficiently update-to-date (e.g. latest Docker on Debian Stable).
Does Docker use user namespaces by default? Otherwise root in the container is actually root on the host, from what I read. Correct me if I'm wrong.
(Privileges are still limited by seccomp filters blocking some syscalls, and there's SELinux to block some other stuff, but it's still the actual root user without user namespaces, I think?)
That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns.
Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.
Root is not just one thing on modern Linux, almost all in-kernel privilege checks are now gated via (slightly) more fine-grained capabilities and the default capability set for Docker containers disallows module loading (CAP_SYS_MODULE) and the relevant syscalls (namely (f)init_module) are also blocked with seccomp.
People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.
Presumably Docker's seccomp profile [1] blocks the init_module system call which is used by insmod [2]. Although, looking at the default profile, it seems to explicitly allow it - but maybe only if you have CAP_SYS_MODULE, which I think means running Docker with "--cap-add=SYS_MODULE".
There are a million ways to load a kernel module from inside of a container into the host kernel (ie: to trigger a load), but seccomp/ linux caps will block the direct ways (as another commenter notes).
Hmm. Either I've lost my mind, or you're running a different Docker than me, or you're thinking of some strange scenario such as a Mac where docker is actually inside a VM, or you're wrong.
While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.
Therefore root in the container very much is root on the host.
I don't think this would change anything even if it were true, which it is not. Running as root in a container opens up tons of footguns but it is not a path out of the container on its own.
My mistake, leaving out some adjective one could interpret as a misunderstanding of containers as an effective (etc.) security boundary. Fool me 100+ times and all that.
There must be at least a triple-digit number of CVEs by now demonstratimg that in practice containers are a thinner layer of security (perhaps not quite as thin as the classic recommendation of running SSH on a nonstandard port, but that might be leaning toward the safer side of analogies vs. malicious code!) rather than a boundary like virtualization (not perfect but a best practice for isolation).
Runpod, digital ocean's gpu cloud, and at least a few others use Linux containers for isolation between tenants (look at Wiz's blog post about the nvidia container toolkit bug; digitalocean just puts everyone in a massive k8s cluster)
