Wrapper to restrict builder access through ssh, worth upstreaming?

Development
1

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" ''
    case $SSH_ORIGINAL_COMMAND in
      "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
        exit
    esac
  '';
6 Likes
2

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

3

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

1 Like
4

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:

5

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?

6

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:

3 Likes
7

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.

8

Thank you, @Solene . This helped us.

Perhaps the wrapper script being in nixpkgs would be a good start for reuse. As for a NixOS option… I’m skeptical, but maybe. The “API” provided by SSH seems rather restrictive. A line in a file, that also contains a public key (which could be considered a secret). But I guess more awkward things have been nixified?

9

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.

Sorry for the late question to this thread. But wouldn’t that require to still craft the malicious script with the same hash than the upcoming good one, hence require to craft a hash collision? Or did I understand something wrongly about how the Nix store works?

10

nixos-modules has a module that implements the script from the original post and that could be upstreamed as is from my perspective.