Hi, I would like to kick off a discussion about an idea that I had that keeps on coming up in Nix discussions. I want to involve the wider community because the gist of the idea is moving responsibility from Nix to the OS, so I want to make sure that NixOS maintainers are on board with this.
Essentially the idea is that instead of Nix doing authentication, the OS should do it. In particular, there should be separate trusted and untrusted socket files. Nix will then “blindly” accept incoming connections as trusted and untrusted (respectively) on each of those sockets. Security is instead done by the OS limiting access to those sockets, instead of Nix vetting connections as they come in.
Merely chowning and chmoding the socket is possible on any Unix. Additionally, systemd can easily declare two sockets, and the SocketUser, SocketGroup, and SocketMode settings can declaratively specify the same result.
NIX_REMOTE can be set conditionally so that the appropriate socket is used by default.
I like this because I would rather not have security-critical logic in Nix itself, and the OS has to implement this functionality anyway. This also dovetails with work we are already considering to use Accept=yes (as Lix does), which likewise moves logic (in this case, the accept loop) outside of Nix (and into systemd, which is not the kernel but also can be considered part of the OS).
Of course, we wouldn’t just rip the logic out of Nix, but if NixOS did the new strategy by default, we could deprecate the old way in Nix.
I’m just a random nix/nixos user, but that sure makes sense to me. Don’t reimplement things, especially security-critical things, when there’s a perfectly serviceable alternative available with a lot more eyeballs auditing it for vulnerabilities.
That would restrict access to a single group if ACLs aren’t used and I don’t know if systemd can set ACLs on Unix domain sockets[1].
Not according to POSIX, Linux however does require write permissions to connect to a Unix domain socket.
POSIX does require search (x) permission on all parent directories and given the lack of ability for systemd to set ACLs on UNIX domain sockets, I’d recommend that both sockets should be in dedicated directories with the appropriate ACLs set.
It can set ACLs on files and folders through tmpfiles.d however I don’t know if tmpfiles.d can be forced to run after creating the sockets ↩︎
That being said, this direction has been postponed for now as testing ACLs in the sandbox requires lifting the sandbox limits on xattrs, which requires having more than 3 UIDs in the sandbox as programs assume that working xattrs syscalls means more than 3 UIDs in the environment.
Until we finish preparing the ecosystem for supporting builds with xattrs operations in the sandbox, we do not plan on resuming work on this.
Regarding only one group: is that actually a problem? I am having trouble imagining use cases where one cannot just…put all the users in a single group. There are tons of other NixOS services that work this way, right?
It is also good to hear that systemd could be persuaded to add more features in the future. I suppose it’s even conceivable that there could be a single socket like today, and systemd could demultiplex connections to different Accept=yes services based on authentication. That would avoid the need for ACLs.
I think I should go make a NixOS PR that would implement the original (two socket, no systems changes) plan on an opt-in basis. We can then see empirically how often the single-group set-up suffices in practice.
And I can open an issue / mailing list thread with systemd to discuss those extensions separately.
I see no problem with requiring the users to be in one group. We do that all the time things like audio, docker, etc.–the group basically becomes a caps grant.
Anything that lets us just defer to existing, sound OS primitives is a win.