Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: Gentoo Developers <gentoo-dev@l.g.o>
Subject: [gentoo-dev] Redux: 2004.1 will not include a secure portage.
Date: Thu, 25 Mar 2004 01:57:20
In Reply to: [gentoo-dev] 2004.1 will not include a secure portage. by Kurt Lieber
1 OK, after reading this entire thread, I've been thinking about a usable
2 implementation from both the administrative and developer perspective.
3 One of the most important things to remember in designing this, is that while
4 you can prevent damage from most individual attacks, no system in existence can
5 withstand a multi-faceted all-out assault.
7 Goals:
8 ------
9 - protect against compromised developer box / rogue developer
10 - protect against compromised rsync server
12 Required operations:
13 --------------------
14 1. add a key to trusted list
15 2. remove a key from trusted list
16 3. verify that a package has not been tampered with
17 4. sign a package
19 General idea:
20 -------------
21 we have a list (single file) distributed via rsync with all of keyids known
22 good for signing manifests. this file is must also signed, with at least one
23 (two or three required for more security) master key that has it's public part
24 widely published and it's private part kept secure. the verifiable signatures
25 on the trust list make it trusted. The signature for the list should be
26 available individually so that it can be checked frequently by portage for
27 changes (and if it has changed, download the list again). Some other users have
28 suggested using expiry times in various ways but that ignores the fact that a
29 portage tree snapshot taken in a known good state remains in that known good
30 state until altered.
32 Signing a package:
33 ------------------
34 manifests are signed as clear-text INSIDE the Manifest file (my prototype
35 already did this). this is important not to bloat the tree with more files.
36 This also allows multiple signatures on a Manifest (basically it just nests).
37 add a command to repoman, 'repoman sign' that signs a manifest and have repoman
38 commit check that a valid signature is present before committing (and
39 automatically does the sign stage on commit if required).
41 to add a key to the trusted list:
42 ---------------------------------
43 1. add keyid into list
44 2. resign modified list with all required master keys
46 to remove a key from the trusted list:
47 --------------------------------------
48 1. remove keyid from list
49 2. resign modified list with all required master keys
51 to verified that a package has not been tampered with:
52 ------------------------------------------------------
53 1. read in manifest file, check that the signature(s) are valid.
54 2. grab the keyid(s) that it was signed with, and compare them against the
55 trusted list (and optionally a LOCAL list for users to have their own trusted
56 key structure)
58 users can specify how many signatures a package needs to have for them to trust
59 it, eg a really paranoid user may require each manifest has at least 3
60 signatures.
62 problem case examples:
63 ----------------------
64 case 1: an rsync server is compromised
65 ======================================
66 if intruder modifies an ebuild/patch it doesn't pass the manifest check
67 anymore, and if they modify the manifest, they need a key to sign it which
68 won't be in the trusted list. if they modify the list it won't pass the
69 external signature checks anymore. this case is made mostly airtight for the
70 users that enable security checks.
72 case 2: a developers box is compromised
73 =========================================================
74 this is a weakness in all of schemes floating around already. on discovery, the
75 keyid is removed from the trust list and an advisory issued. users requiring at
76 least N signatures on a package are protected unless the intruder hacks N
77 developer boxes. Assuming that developers keep their gpg keys with a pass-phrase
78 as they should (just like their ssh keys), there is minimal danger until
79 ssh/gpg are trojaned to capture the unencrypted key/pass-phrase.
81 case 3: rogue developer
82 =======================
83 this is one of the hardest things to catch in any system. just like in case 2,
84 users requiring at least N signatures are safe until N developers are
85 rogue/compromised.
87 possible problems with this approach:
88 -------------------------------------
89 for users that specify more than 1 signature must be on a manifest, it's very
90 hard to keep manifests in this state if the package changes often, since any
91 package change requires redoing the manifest which removes the old signatures.
92 this could be fixed by making manifest building incremental (eg it is NOT
93 regenerated from scratch but instead appended until an old set of signed data
94 no longer applies to any files [as they have all been changed]), but that would
95 require a re-write of the manifest generation code.
97 Plan for incremental implementation:
98 ------------------------------------
99 1. roll out portage with a cleaned up version of my prototype for repoman and
100 simple verification code for manifests ONLY.
101 2. create the trusted list and roll out a portage with support for it.
103 --
104 Robin Hugh Johnson
105 E-Mail : robbat2@××××××××××××××.net
106 Home Page :
107 ICQ# : 30269588 or 41961639
108 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85