Security of Nixpkgs Repository

Development Security
1

I’m an academic researcher (and Nix enthusiast!) interested in software repository security – specifically, how to protect users from compromised repositories (as opposed to bad packages served legitimately). The rough “best practice” in this space is The Update Framework (TUF). I think the reproducibility of Nix, plus a secure repository, will lead to the best software supply chain we have.

I’m interested in two things: a general discussion about the impact of repository security in Nix, and understanding the nixpkgs use case a little better.

Nix + Repository Security

Software repositories are a huge target. In particular, when using NixOS out-of-the-box, you’re trusting at least:

  • GitHub (or wherever you’re getting nixpkgs from)
  • Everyone with commit access to nixpkgs (to catch issues and to not be malicious)
  • cache.nixos.org

There’s a bunch of ways this can go wrong, from outright malware (bad packages), to deliberately serving old/incompatible package versions.

TUF is an approach to repository security that aims to (1) minimize the damage any one party can do, and (2) allow recovery after a compromise. The main idea is to run your own little PKI (with offline root keys) and to assign different “roles”: each package has an owner that must sign it, someone’s responsible for compiling a consistent/coherent manifest of packages, and someone attests that the current manifest is up-to-date. (Each of these can require some threshold of several users).

I’m not necessarily advocating wholesale adoption of TUF in nix/nixpkgs, but I wonder if there are aspects we can adopt.

(I also haven’t totally digested the current security practices, so my understanding may be incomplete.)

Understanding nixpkgs

As part of a current project (early stages; will be happy to share details as the work matures) I’m interested in the specific usage patterns of various software repositories. That is:

  • how often do users nix-channel --update?
  • how often do users download packages?
  • how often are packages updated?
  • how big are packages?

Is there anyone I might be able to chat about some of these with? (I could share details of our project.) High-level details would help us build solutions that work well at the scale of nixpkgs.

CC: NixOS security team (@gchristensen, @fpletz, ), @mlieberman85 (related to this discussion – I’m tangentially involved in the CNCF work as well).

1 Like
2

I think this RFC is related.

1 Like
3

Thanks!

@L-as would be quite interested in discussing further with you.

4

We can arrange a call, but we could also do it within the context of shepherdship of the RFC. What do you think?

5

I think a quick call would be nice to hash out a lot of ideas really quickly; we can then summarize on the RFC. I’ll send a message.

6

All binary cache packages are signed, and there’s a verification of substitutes done before accepting the NAR.

$ cat /etc/nix/nix.conf | grep -e keys -e substituters
substituters = https://cache.nixos.org/
trusted-substituters =
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
1 Like
7

All binary cache packages are signed, and there’s a verification of substitutes done before accepting the NAR.

I think that’s consistent with my point: if you compromise that one key, you can get bad binaries onto users’ machines (even if Nixpkgs was signed+verified)—it’s a single point of failure.

(Sorry if that’s what you were saying and I misunderstood you!)

It seems like we really need to enumerate all the (many) people/servers/keys you’re implicitly trusting when you install NixOS, and only then can we start working on ways to mitigate various attack vectors (just having everything be signed isn’t particularly efficacious—often you’re not really getting any additional assurance).

Edited to make context clearer.

1 Like
8

P.S. We started a dedicated matrix channel for people interested in supply-chain security. Feel free to drop by! Over $10 Million donated for Supply Chain Security - An opertunity for growth and adoption - #2 by kamadorueda

3 Likes
9

Direct link: https://matrix.to/#/#nix-slsa:matrix.org

Also this article is very interesting around Guix implementing some of the aspects from TUF where they apply: Securing updates — 2020 — Blog — GNU Guix

I’d note it might be worth nixpkgs looking into PR automation kind of like prow where we can allow maintainers to mark a package as ready for merging so less people need merge permissions

pr-interactions-sequence
pr-interactions-sequence2650×1396 102 KB

As a note around the RFC, the git signing in github it’s pretty useless unless you distribute public keys elsewhere and validate that too.
If an attacker gets access to your GH account they can just change the signing key attached to the account and it looks 100% legit. If it’s also somewhere else they need to change that too making it much harder.

1 Like
10

As a note around the RFC, the git signing in github it’s pretty useless unless you distribute public keys elsewhere and validate that too.
If an attacker gets access to your GH account they can just change the signing key attached to the account and it looks 100% legit. If it’s also somewhere else they need to change that too making it much harder.

Yeah, I think something like what Guix does (.guix-authorizations file in source) is a pretty reasonable approach.

2 Likes