1 |
Hey guys, |
2 |
|
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. |
14 |
|
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. |
31 |
|
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: |
36 |
|
37 |
- Signatures are made by developers, not by infra. |
38 |
- Portage doesn't see any files that haven't yet been verified. |
39 |
|
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. |
47 |
|
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. |
51 |
|
52 |
Jason |