Generally speaking, if this is happening, it’s likely that the untrusted code can already wreak as much havoc as it wants. That is to say, if Nixpkgs or another flake input you use were backdoored, there are a myriad ways they could be backdoored that would compromise your system regardless of the build sandbox. That’s what I meant in my previous post: it’s very rare for normal users to be in a situation where the kind of vulnerability being described will have any effect on them.
If the vulnerability matches the description given – “All systems building untrusted derivations are impacted.” – the vast majority of users are unlikely to be affected in any way. It’s as safe to update Nixpkgs and rebuild your system is now as it will be once the vulnerability is patched. If Nixpkgs is backdoored or you have untrustworthy flake inputs, you almost surely have bigger problems than whatever this build sandbox issue is.
tl;dr if you don’t know what an untrusted derivation is you’re basically guaranteed to be safe. (Or at least no more in danger from this vulnerability specifically.)
@emily@nat These are both very helpful and actionable!
basically once the vuln is disclosed and patch is merged/out in channels, update only nixpkgs first. Before disclosure you can do pretty much whatever you want
Am I guessing correctly that to “update only nixpkgs,” I would look through the output of nix-channel --list, find the most relevant-looking channel, and then call nix-channel --update [channel name] to update it?
That is to say, if Nixpkgs or another flake input you use were backdoored, there are a myriad ways they could be backdoored that would compromise your system regardless of the build sandbox. That’s what I meant in my previous post: it’s very rare for normal users to be in a situation where the kind of vulnerability being described will have any effect on them.
tl;dr if you don’t know what an untrusted derivation is you’re basically guaranteed to be safe. (Or at least no more in danger from this vulnerability specifically.)
That does clarify your previous post for me. Thanks!
To be clear, @nat’s advice may be true in the general case but I disagree with it for the average user.
Let’s say you have a flake input providing a third‐party package that you use. You might be worried that it could be updated to maliciously exploit this vulnerability to escape the build sandbox.
Okay, that sounds pretty bad! But if the source of the package is malicious, then it could just install the malicious code in the resulting built package instead. You’d run the program as normal and it’d execute the malicious code entirely outside of the build sandbox. So the build sandbox was never protecting you anyway and this vulnerability would be a needlessly complicated way of owning your system.
There’s ways this vulnerability could potentially be worse than just running code directly as your user – for instance, maybe it lets builds become root? But in practice it’s pretty easy for any malicious program running as your user to arrange to escalate to root privileges anyway unless your system setup is extremely locked down.
Therefore, build sandbox issues usually only matter if you are building packages but not running them. This is true mostly of public CI/build servers and people who run nixpkgs-review a lot. Unless there is more to this vulnerability than is implied by the pre‐announcement, I believe that most users can ignore it entirely. (But of course it’s still a good idea to update once the fix is out.)