It's a race condition that can be used as a primitive to achieve privilege escalation which makes it legitimate but even if it you couldn't use it for anything else but to trick the system into acting on a directory it didn't meant to it would still be a valid vulnerability (regardless of the application).
Claiming it's not a valid bug would be similar to claiming an infoleak isn't as well when it's one of the building blocks of modern exploitation.
I'm not trying to be an ass, I'm just trying to add a bit of context to ensure that the implication is well understood.
But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.
Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaining the system itself.
I never asked around so maybe that's on me. Debian works just fine though and containers are (usually) simple enough for me to wrap my head around.
I didn't end up using Flatpak for the same reason.
When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?
The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.
I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
NixOS is incredibly complicated at build time, but the filesystem & runtime state is pretty simple. Run it in a VM and look around, there's very little magic at runtime; the trickery is mostly in the build time rpath hack to load shared libs from the specific /nix/store paths, and a lot of configuring software to read files from specific /nix/store paths.
Comments
Better to follow the link to the technical details and just read those: https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys...
The article linked in the submission is more verbose but less clear and half of it is an advertisement for their product.
I love that cheeky "oh btw, there's also another vulnerability in rust coreutils rewrite, but we aren't talking about that" paragraph
That's because it's not a vulnerability per se. They found a way to use `rm` as a gadget for their privilege escalation.
The core problem is that there's a world-writable directory that is processed by a program running as root.
It's a race condition that can be used as a primitive to achieve privilege escalation which makes it legitimate but even if it you couldn't use it for anything else but to trick the system into acting on a directory it didn't meant to it would still be a valid vulnerability (regardless of the application).
Claiming it's not a valid bug would be similar to claiming an infoleak isn't as well when it's one of the building blocks of modern exploitation.
I'm not trying to be an ass, I'm just trying to add a bit of context to ensure that the implication is well understood.
But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.
Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaining the system itself.
I never asked around so maybe that's on me. Debian works just fine though and containers are (usually) simple enough for me to wrap my head around.
I didn't end up using Flatpak for the same reason.
When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?
The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.
I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
NixOS is incredibly complicated at build time, but the filesystem & runtime state is pretty simple. Run it in a VM and look around, there's very little magic at runtime; the trickery is mostly in the build time rpath hack to load shared libs from the specific /nix/store paths, and a lot of configuring software to read files from specific /nix/store paths.
This.
Might be worth updating the link.