Ludovic CourtèsJun 24

So, there’s much to be said about these vulnerabilities…
https://guix.gnu.org/en/blog/2025/privilege-escalation-vulnerabilities-2025/

First, thanks to fellow Nix and Lix hackers for sending us a heads-up, for sharing Snyk’s detailed report, and for coordinating with us. 👍

Privilege Escalation Vulnerabilities (CVE-2025-46415, CVE-2025-46416) — 2025 — Blog — GNU Guix

Blog posts about GNU Guix.

Show threadLudovic CourtèsJun 24

The fix has been 3 months in the making (!) and that was far from trivial.

Reepca (whose review work on the rootless guix-daemon had been instrumental) has been doing almost all the development work in Guix.

It’s an impressive piece of work, including in terms of the size of the diff—the biggest in the entire history of ‘guix-daemon’.

Show threadLudovic CourtèsJun 24

Reepca will share their thoughts on this later, but it’s hundreds of lines of code 👇

25 files changed, 2855 insertions(+), 550 deletions(-)

… to “just” work around a couple of Linux design flaws.

We’re plugging a user-level network stack (slirp4netns) + namespaces + seccomp filters just because abstract Unix-domain sockets are (1) ambient authority in a global name space, and (2) associated with “network namespaces” instead of some IPC namespace.

Show threadLudovic Courtès
It’s fundamentally wrong that we have to pull in so much additional code (that includes slirp4netns and seccomp) to plug the holes.
Jun 24 at 8:54pmWeb
Show threadcancernameJun 24
@civodul To be fair, the TOCTOU stuff is mostly a result of using paths instead of directory fds (known-broken for some 20 years). I do agree that it would be nice to have abstract unix sockets in ipc ns, but I can also see why they are in net ns, they are sockets after all.
Show threadLudovic CourtèsJun 25

@cancername Yeah, the TOCTOU issues is mostly addressed by the *at family of functions.

As for abstract Unix-domain sockets, I think they’re really local IPC; having them in the net namespace causes so much trouble.