when a substituter is untrusted, give a solution in the warning message

[rapenne-s]

Describe the bug

When running a flakes program through nix run that is providing a substituter, the warnings messages in the current code are not really helpful.

Steps To Reproduce

1. run nix run github:tweag/nickel -- --help
2. answers y to the multiple questions about a substituter
3. you will see a message warning: ignoring untrusted substituter 'https://nickel.cachix.org'

Because you accept all the questions about trust, it's confusing to see the substituter is ignored because it is untrusted.

Expected behavior

I think the last warning message should add a solution: [...], if you want to use this substituter, either add your user to the trusted-users list, or add the substituter to the trusted-substituters list in your Nix configuration.

nix-env --version output : nix-env (Nix) 2.9.1

Additional context

My user is not a trusted user and the substituter wasn't listed in the trusted-substituters. Setting one is enough to have the cache enabled.

[jonringer]

Just stumbled upon this, very odd user experience.

Nix version: 2.10.3

[jonringer]

Fix for me was to use trusted-substituters (or extra-trusted-substituters) instead of extra-substituters since the extra- get's pruned with the setting merging logic

nix/src/libexpr/flake/config.cc

Line 38 in 9d860f3

auto baseName = hasPrefix(name, "extra-") ? std::string(name, 6) : name;

and substituters isn't a valid nix.conf value.

[mitchmindtree]

Fix for me was to use trusted-substituters (or extra-trusted-substituters) instead of extra-substituters since the extra- get's pruned with the setting merging logic

@jonringer I'm not sure this workaround has the same semantics. It looks like trusted-substituters aren't used by default (unlike substituters), and only indicate the set of substituters that an underprivileged user can pass to --substituters.

That said, it's not clear to me what the meaning is of an underprivileged user building a flake with custom trusted-substituters values (or any of the trusted- values) and accepting those values 🤔

[ParetoOptimalDev]

Maybe a separate issue, but it seems you cannot successfully set trusted-users in a flake. Can anyone reproduce this? I'm using Nix 2.11.0.

Edit: It seems that this only happens from NixOS and not from some other OS just using the Nix package manager.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/ux-problems-with-flakes-and-custom-caches-substituters/23691/1

[tomberek]

Random thoughts:

• include some context to declare the user's trusted status or lack thereof
• provide a printout of the relevant settings

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-12-09-nix-team-meeting-minutes-15/23951/1

[fricklerhandwerk]

Discussed in Nix team meeting on 2022-12-19:

@rapenne-s: Please make a two-line warning that directs the user to man nix.conf for trusted-substituters. Add the instructions to that option documentation, and a link from the related sections to that place such that it can be found from different contexts.

Complete discussion

• @edolstra: it would be really annoying if that warning appears every time you run Nix and you can't do anything about it
  • it would be better to improve the manual
    • @fricklerhandwerk: add the information to the manual to both configuration options, and reuse the text in the error message. and instructions in the error message how to find it
      • @edolstra: the error message is not markdown
        • @fricklerhandwerk: can use a subset that works in both contexts for now, come up with a more general setup later
      • @thufschmitt: it would be better to have a direct link
        • would be best if we could link to a particular version of the manual
        • @fricklerhandwerk: can't realistically maintain the URL. having versioned manuals is a different issue (but important!)
  • also it would be great if we could direct people to a particular section in the offline documentation
• (more discussion on how to deal with helping users to navigate the offline manuals)
• decision: make a two-line warning that directs the user to man nix.conf for trusted-substituters, add information to the relevant sections in the manual

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-12-16-nix-team-meeting-minutes-17/24120/1

[blaggacao]

As a provider of nix services to my team, as soon as nixConfig has been committed to the repository, I'm the anchor in the chain of trust, neither the super-user, nor the daemon nor anybody or anything else.

^^ These are the true semantics (in the case of having nixConfig in a flake) that need to be reflected in an ergonomic way in the Nix CLI.

Maybe that implies not recommending daemon mode for some use cases.

[rapenne-s]

Just add yourself as a trusted user and it works like you want.

[blaggacao]

That's what I ended up doing, indeed. Not sure about the Nix-native UX on this topic, at this point.

[towry]

sudo vim /etc/nix/nix.conf

trusted-user = root @staff user_name_abc

restart daemon maybe.

[samuela]

For folks who are reading this and unsure how to restart nix-daemon:

sudo systemctl restart nix-daemon

Ideally it would auto-recognize config updates: #8939

[fjolne]

On NixOS instead of editing nix.conf you should add a setting to /etc/nixos/configuration.nix. Beware of security implications of adding yourself to trusted-users #9649 (comment), better to add trusted-public-keys and substituters.

  nix.settings.trusted-public-keys = [ ... ];
  nix.settings.substituters = [ ... ];

[brainrake]

Caution

DO NOT add your user to trusted-users, it makes your user root without password!

Add trusted-public-keys and substituters or trusted-substituters to your system config instead.

We should not recommend this for everyday use as it is a pretty severe security issue.

[rapenne-s]

Maybe these persons already have a passwordless sudo anyway, adding their user to trusted-users is just the cherry on the cake

[brainrake]

Regardless, we should not encourage it.

[fjolne]

@brainrake Thanks, I shouldn't have suggested that indeed: fixed my comment. I don't use trusted-users myself anymore for that reason, but I started with that option after seeing comments above and that was when I wrote the comment.

[samuela]

DO NOT add your user to trusted-users, it makes your user root without password!

Thanks for this heads up @brainrake!

Add trusted-public-keys and substituters or trusted-substituters to your system config instead.

ooc what's the difference between substituters and trusted-substituters? why would i ever want to list a substituter that is untrusted?

[YorikSar]

ooc what's the difference between substituters and trusted-substituters? why would i ever want to list a substituter that is untrusted?

substituters are always enabled, trusted-substituters can be enabled on demand by untrusted users. See https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-trusted-substituters

[brainrake]

both are trusted :/

[samuela]

Hmm so are the nix.conf docs out of date?

[brainrake]

No. The name is misleading.

[samuela]

the docs seem to indicate that they have different semantics but iiuc your comment implies that they do the same thing?

[brainrake]

Both are trusted. But trusted- is only trusted, not used by default, only used if added via user nix.conf or flake.

[samuela]

Ahh... ok so to confirm my understanding:

• trusted-substituters specifies that a substituter is trusted on the system, but does not enable it in builds by default. Users are then entitled to specify their own substituters, which must be a subset of the global trusted-substituters.
• substituters in /etc/nix/nix.conf specifies the global default substituters list for use by all builds. Users can override this setting but they must set it to some subset of the global trusted-subsituters.

Put another way, substituters implies trusted-substituters, but not vice versa... does that sound right?

[brainrake]

About right, except substituters can be extended, not overridden.

[dpc]

Can I somehow just hide this message? I'm using a flake that advertises a binary cache. But myself I don't use that cache, so I answer "don't use it", and "yes, remember that choice". I don't want to be bother about it anymore, yet on every build I have to see this warnings.

[0cjs]

Maybe these persons already have a passwordless sudo anyway, adding their user to trusted-users is just the cherry on the cake

It doesn't matter; the issue with adding "alternate s3cr3t root access" methods is that now anybody who wants to audit or change that needs to look in two different places. (Adding users to the docker group has the same issue.) To avoid obvious security pitfalls, you should be able to tell if a user has root access by looking only at her sudo capabilities, and removing sudo capabilities that give root access should actually remove root access, not just remove one of several methods of getting root access.

[ntc2]

First time Nix user here, and I didn't find the new warning message sufficient. In particular, I didn't see any mention in the man nix.conf that I needed to restart the daemon (#6672 (comment)) for changes to the global /etc/nix/nix.conf to take effect. This was very confusing, because before this I had only edited the local ~/.config/nix/nix.conf, where the changes take effect immediately (but where the settings for substituters don't work).

More context, I assume this is a typical experience: I've never used Nix before, and just joined a new project that uses Nix. The project README tells me I need to run nix develop. After installing the latest stable version of Nix I have problems related to no such nix develop command and no support for flakes (resolved by adding experimental-features = nix-command flakes to my local config). Then nix develop finally runs and I respond y to a bunch of questions about trusted substituters and trusted keys, and then have the problem this ticket is concerned with.

[agubelu]

Caution

DO NOT add your user to trusted-users, it makes your user root without password!

Add trusted-public-keys and substituters or trusted-substituters to your system config instead.

We should not recommend this for everyday use as it is a pretty severe security issue.

Why is this so? It doesn't seem reasonable, something that looks like a Nix-specific config should not have such a massive security side-effect.

[0cjs]

Since nobody's bothered to answer the above, I'll give it a try. I don't know the exact details here, but the issue is most likely that you're trusting all your subtituters to provide packages built to exactly the formula of each package, without you having any good way to verify that yourself (except to compare it with your own build, but doing that would make substituters pointless). That means you're trusting them not to provide a substitution that includes malicious code that might be run by root, or even malicious suid binaries.

This general problem is not Nix-specific; it's the nature of downloading from the Internet binaries that someone else has built.

[agubelu]

Sure, but I don't see how that's relevant to making your user sudo without password as a side-effect.

The trust issue applies to any configuration manager. When I run pip install requests I trust the requests repo to not have been compromised and distribute malicious code (that would perfectly match the expected hash). I trust pip itself to not have been compromised and go rogue. If I add a source to trusted-substituters in Nix, I'm making the same decision regarding trust.

But since security isn't perfect, I don't run anything as root unless I have good reason to. If anything, trust should be a reason against liberally relaxing root privileges. Maybe I misunderstood your point, but this reasoning sounds like "if anything bad happens, we'll make sure it's as bad as it can possibly be".

[0cjs]

...to making your user sudo without password...

Just to be clear, by this I assume you mean, "can gain root access," not literally "sudo without password."

The trust issue applies to any configuration manager. When I run pip install requests I trust the requests repo to not have been compromised and distribute malicious code (that would perfectly match the expected hash).

This same trust issue does not apply to Pip in this way, for two reasons.

1. You're not running Pip as root, so it can't install suid root programs, or change programs or configuration files that root trusts. (Or you are running Pip as root, in which case you presumably understand the risks you're taking.) Nix, on the other hand, is often run in a configuration where the install does happen as root.
2. pip install is installing an exact package build from a single source. What you are requesting with Nix substituters is to install a potentially (and in most cases, probably) different package build from your alternate source.

Adding a different trusted-substituters for Nix, especially when it's running in the usual configuration of installing as root rather than as the user, is the same kind of thing as using apt-get to install packages from another source without confirming the hash of the built package.

...I don't run anything as root unless I have good reason to...

So you always install and run Nix in single-user mode? If that's the case, you're protected against such attacks. But then you also, IIRC, don't have a problem changing trusted-substituters without root access.

But many people run Nix in daemon mode, and these people are taking actions as root when they install packages using Nix. And thus, correctly, they should not be able to get binary packages from arbitrary sources to be installed as root (and potentially run as root) without having root access themselves to say that the substituter is trusted.

[NobbZ]

@agubelu To (partially) answer your question:

A trusted user can craft and inject storepaths at their will, this way they could provide something that a NixOS would potentially link in a security-wrapper assuming it was a legit sudo or anything.

This attack is rather unlikely, and a certain config has to be targetted with it.

@viperML once went through the process and attacked his own machine that way and succeeded. I thought he wrote a blog post about it, though I can not find it in his personal blog.

As a sidenote: from what I understand, this attack is only relevant against NixOS and maybe nix-darwin, due to the security wrappers.

[brainrake]

@NobbZ the more concerning attack is local privilege escalation. Anyone in trusted-users gets root on the local machine. The exploit is trivial:

NIX_CONFIG="post-build-hook = whoami" nix build nixpkgs#hello --rebuild --print-build-logs

or even

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

In addition, accept-flake-config also allows overriding trusted-users from a flake with no warning so should not be used. #9649

The attack works on any system running nix-daemon as root ("multi-user installation"), not just NixOS and nix-darwin. The solution being worked on is making nix-daemon work without root. #5380

[brainrake]

@agubelu @0cjs the reason is history. trusted-users was added as convenince (and necessary for some use cases like CI) and to be fair the manual warns against its use
https://nix.dev/manual/nix/2.23/command-ref/conf-file#conf-trusted-users
But of course people and software started to (ab)use and recommend it without always knowing the context. So we need a better design.