(Allow) limiting network access in fixed-output derivations

[Ekleog]

Talking on #nixos-security with @andir about the impact of potential flaws in curl, summing up outcome of the discussion here.

A potential impact would be to have someone exploit a flaw in curl to execute code with full access to local (and remote) network, and exfiltrate information from there.

A solution would be to add arguments to fixed-output derivations so that they can be run with limited network access, in particular with an IP/DNS whitelist. Said IP/DNS whitelist would be automatically set by lib.*, based on the arguments they have. This way, a flaw in curl would be mitigated against.

DNS whitelists with iptables are not really efficient, but should likely be good enough for our purposes, I guess?

What do you think about it?

[copumpkin]

@Ekleog trying to figure out the threat model here. If a fixed-output derivation expression is compromised to steal local network data and exfiltrate it to the public network, wouldn't the lib whitelist be trivially compromisable too? It seems like this would only address a literal 0day in curl rather than the more likely "one of the 100+ contributors to nixpkgs sneaks malicious code into one of our FO builders"

This gets me thinking though: could we by default at least deny RFC 1918 private IP ranges (and 169.254 for good measure) from FO derivations? That seems like it would cover at least some of your concern, and in 99% of cases would do what people expect (every FO derivation I have, including internal ones at my company, hits public IP ranges). Then if you want to allow it, you pass an --option allow-fixed-private-network-access true or something to the Nix command line.

[vcunat]

Threat model: I think he meant that the derivation itself is trusted, but malicious http(s) server (or MITM) could take control of the vulnerable curl. BTW, in case curl had such problems, it would be difficult to safely build from older nixpkgs versions (unless all the sources are there or obtained in another way).

I'm afraid that fixed-output derivations aren't enough, as e.g. downloads from the binary cache are done by nix+libcurl directly IIRC. On the other hand, the nix daemon itself will often need access to local network e.g. because of remote builders.

[7c6f434c]

BTW, a whitelist of all things that are allowed to generate FO derivations with network access could be useful if most PRs could be automatically be verified as «not doing anything fancy with network». I think the theoretical risk of weird FO derivations is a part of reason why letting everyone trigger ofborg builds is considered risky, not just resource-intensive.

Not sure what would be a good approach to implementation, though.

[Ekleog]

@copumpkin Basically what @vcunat said. Also, in my opinion if one of the contributors to nixpkgs sneaks malicious code into nixpkgs, then the game is already over anyway, as they can just add in a patch that inserts a backdoor into any executable they want, which will later be run outside of the sandbox, so I don't think that's really something we can reasonably defend against.

[FRidh]

Related issue #2270

[stale[bot]]

I marked this as stale due to inactivity. → More info

[stale[bot]]

I closed this issue due to inactivity. → More info