Gentoo Archives: gentoo-dev

From: "Jason A. Donenfeld" <zx2c4@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Trustless Infrastructure
Date: Mon, 02 Jul 2018 15:36:41
1 Hey guys,
3 While our infrastructure team has some nice technical competence, the
4 recent disaster and ongoing embarrassing aftermath has made ever more
5 urgent the need to have end-to-end signatures between developers and
6 users. While the infrastructure team seems fairly impressive at
7 deploying services and keeping the house running smoothly, I'd rather
8 we don't place additional burden on them to do everything they're
9 doing securely. Specifically, I'd like to ensure that 100% of Gentoo's
10 infrastructure can be hacked, yet not backdoor a single witting user
11 of the portage tree. Right now, as it stands, rsync distributes
12 signatures to users that are derived from some
13 infrastructure-controlled keys, not from the developers themselves.
15 Proposal:
16 - Sign every file in the portage tree so that it has a corresponding
17 .asc. Repoman will need support for this.
18 - Ensure the naming scheme of portage files is sufficiently strict, so
19 that renaming or re-parenting signed files doesn't result in RCE. [*]
20 - Distribute said .asc files with rsync per usual.
21 - Never rsync into the /usr/portage directory, but rather into an
22 unused shadow directory, and only copy files from the shadow directory
23 into /usr/portage after verification succeeds. (The fact that those
24 files are visible to portage prior to verification and following a
25 failed verification is a shameful oversight of the current system.)
26 - Have verification use a keyring of all Gentoo developers, with a
27 manual prompt to add new Gentoo developers to it.
28 - Eventually acquire (sponsors?) nitrokeys/yubikeys for all
29 developers, and mandate everyone stores their Gentoo key material in
30 there exclusively.
32 This is very similar to what Arch Linux is doing, and AFAIK, it works
33 well there. I'm sure this list will want to bikeshed over the
34 particulars of the implementation, but the two design goals from this
35 are:
37 - Signatures are made by developers, not by infra.
38 - Portage doesn't see any files that haven't yet been verified.
40 Regarding the [*] comment above about the directory tree. There might
41 be more clever ways of handling this, like having the last developer
42 who modified the tree compute some kind of holistic signature, in
43 addition to each of the individual ones. Or, perhaps, this is the one
44 place where we would consider relying on infrakeys, provided portage
45 isn't victim to clever RCE by rearrangement. Other attacks include, of
46 course, downgrades and DoS.
48 Hopefully we can move Gentoo's portage tree security up to modern
49 security expectations, and no longer be forced to trust vulnerable
50 sitting-duck infra machines for our signatures.
52 Jason


Subject Author
Re: [gentoo-dev] Trustless Infrastructure R0b0t1 <r030t1@×××××.com>
Re: [gentoo-dev] Trustless Infrastructure Rich Freeman <rich0@g.o>
Re: [gentoo-dev] Trustless Infrastructure "Michał Górny" <mgorny@g.o>
Re: [gentoo-dev] Trustless Infrastructure Mariusz Ceier <mceier@×××××.com>
Re: [gentoo-dev] Trustless Infrastructure "Hanno Böck" <hanno@g.o>
Re: [gentoo-dev] Trustless Infrastructure "Michał Górny" <mgorny@g.o>
Re: [gentoo-dev] Trustless Infrastructure Francesco Riosa <vivo75@×××××.com>
Re: [gentoo-dev] Trustless Infrastructure Ulrich Mueller <ulm@g.o>