Wrapper to restrict builder access through ssh, worth upstreaming?

Hi, at work for our remote builder access, we started restrict users to only run the minimum required to speak to the nix daemon. However, we found that the command is different depending if people are using ssh:// or ssh-ng:// in the builder URL.

I came up with a wrapper that depending what you call on the remote ssh server, it will provide you the correct command to match the client, and stop if you try to do something else. It’s working fine so far, but I wonder if it’s something worth upstreaming as a NixOS module or in the Nix documentation.

  # add this before each authorized key
  ssh-restrict = "restrict,pty,command=\"${wrapper-dispatch-ssh-nix}/bin/wrapper-dispatch-ssh-nix\" ";

  wrapper-dispatch-ssh-nix = pkgs.writeShellScriptBin "wrapper-dispatch-ssh-nix" ''
      "nix-daemon --stdio")
        exec env NIX_SSL_CERT_FILE=${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt ${pkgs.nix}/bin/nix-daemon --stdio
      "nix-store --serve --write")
        exec env NIX_SSL_CERT_FILE=${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt ${pkgs.nix}/bin/nix-store --serve --write
        echo "Access only allowed for using the nix remote builder" 1>&2

As it seems there is no interest into this, I wonder how people do manage their builders :sweat_smile:

having a module that sets up remote build users with ssh restrictions, keys, necessary nix permissions etc does sound useful. we’d use it.

the “issue” is that even with that, this allows any user with access to the nix user to compromise the machine through the store if they want. So, it tighten the security, but still allow to compromise the machine… :frowning:

hmmm, I’m not sure i understand

‘compromise the machine through the store’.

Do mean building evil things, and placing them in there or something more?

true, but having a module makes it very easy to roll out future improvements as and when they appear. it might not be perfect, but it’s better than nothing? the module could conceivably gain a sandboxed feature at some point that spawns a container with a dedicated store rather than sharing the host store. or do it in a vm instead. or enable new safety features in nix as they appear. anything is probably better than cargo-culting setup snippets :slight_smile:


yes, for instance, if you use a nix builder on a NixOS system that will be updated soon, you could poison the store by pushing there a bash derivation with the same hash of the one that will land in the update, but compromised.