/[gentoo]/xml/htdocs/proj/en/glep/glep-0058.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0058.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations) (download)
Tue Oct 21 23:30:47 2008 UTC (5 years, 10 months ago) by cardoe
Branch: MAIN
File MIME type: text/plain
add Robin's tree signing gleps. They still need lots of editing love (some won't glep-ify) but at least they're here and have glep #s reserved

1 GLEP: 58
2 Title: Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
3 Version: $Revision: 1.24 $
4 Last-Modified: $Date: 2008/10/09 23:23:12 $
5 Author: Robin Hugh Johnson <robbat2@gentoo.org>,
6 Status: Draft
7 Type: Standards Track
8 Content-Type: text/x-rst
9 Requires: GLEP44, GLEP60
10 Created: October 2006
11 Updated: November 2007, June 2008, July 2008, October 2008
12 Post-History: ...
13
14 ========
15 Abstract
16 ========
17 MetaManifest provides a means of verifiable distribution from Gentoo
18 Infrastructure to a user system, while data is conveyed over completely
19 untrusted networks and system, by extending the Manifest2 specification,
20 and adding a top-level Manifest file, with support for other nested
21 Manifests.
22
23 ==========
24 Motivation
25 ==========
26 As part of a comprehensive security plan, we need a way to prove that
27 something originating from Gentoo as an organization (read Gentoo-owned
28 hardware, run by infrastructure), has not been tampered with. This
29 allows the usage of third-party rsync mirrors, without worrying that
30 they have modified something critical (e.g. eclasses, which are still
31 unsigned).
32
33 Securing the untrusted distribution is one of the easier tasks in the
34 security plan - in short, all that is required is having a hash of every
35 item in the tree, and signing that hash to prove it came from Gentoo.
36
37 Ironically we have a hashed and signed distribution (it's just not used
38 by most users, due to it's drawbacks): Our tree snapshot tarballs have
39 hashes and signatures.
40
41 So now we want to add the same verification to our material that is
42 distributed by rsync. We already provide hashes of subsets of the tree -
43 our Manifests protect individual packages. However metadata, eclasses
44 and profiles are not protected at this time. The directories of
45 packages and distfiles are NOT covered by this, as they are not
46 distributed by rsync.
47
48 This portion of the tree-signing work provides only the following
49 guarantee: A user can prove that the tree from the Gentoo infrastructure
50 has not been tampered with since leaving the Gentoo infrastructure.
51 No other guarantees, either implicit or explicit are made.
52
53 Additionally, distributing a set of the most recent MetaManifests from a
54 trusted source allows validation of trees that come from community
55 mirrors, and allows detection of all cases of malicious mirrors (either
56 by deliberate delay, replay [C08a, C08b] or alteration).
57
58 =============
59 Specification
60 =============
61 For lack of a better name, the following solution should be known as the
62 MetaManifest. Those responsible for the name have already been sacked.
63
64 MetaManifest basically contains hashes of every file in the tree, either
65 directly or indirectly. The direct case applies to ANY file that does
66 not appear in an existing Manifest file (e.g. eclasses, Manifest files
67 themselves). The indirect case is covered by the CONTENTS of existing
68 Manifest files. If the Manifest itself is correct, we know that by
69 tracking the hash of the Manifest, we can be assured that the contents
70 are protected.
71
72 In the following, the MetaManifest file is a file named 'Manifest',
73 located at the root of a repository.
74
75 ---------------------------------------------
76 Procedure for creating the MetaManifest file:
77 ---------------------------------------------
78 1. Start at the root of the Gentoo Portage tree (gentoo-x86, although
79 this procedure applies to overlays as well).
80
81 2. Initialize two unordered sets: COVERED, ALL.
82 2.1. 'ALL' will contain every file in the tree.
83 2.2. 'COVERED' will contain every file that is mentioned in an existing
84 Manifest2.
85
86 3. Traverse the tree, depth-first.
87 3.1. At the top level only, ignore the following directories: distfiles,
88 packages, local
89 3.2. If a directory contains a Manifest file, extract all relevant local
90 files from it (presently: AUX, MISC, EBUILD; but should follow the
91 evolution of Manifest2 entry types per [GLEPxx+5]), and place them
92 into the COVERED set.
93 3.3. Recursively add every file in the directory to the ALL set,
94 pursusant to the exclusion list as mentioned in [GLEPxx+5].
95
96 4. Produce a new set, UNCOVERED, as the set-difference (ALL)-(COVERED).
97 This is every item that is not covered by another Manifest, or part
98 of an exclusion list.
99
100 5. If an existing MetaManifest file is present, remove it.
101
102 6. For each file in UNCOVERED, assign a Manifest2 type, produce the
103 hashes, and add with the filetype to the MetaManifest file.
104
105 7. For unique identification of the MetaManifest, a header line should
106 be included, using the exact contents of the metadata/timestamp.x
107 file, so that a MetaManifest may be tied back to a tree as
108 distributed by the rsync mirror system. The string of
109 'metadata/timestamp.x' should be included to identify this revision
110 of MetaManifest generation. Eg:
111 "Timestamp: metadata/timestamp.x: 1215722461 Thu Jul 10 20:41:01 2008 UTC"
112 The package manager MUST not use the identifying string as a filename.
113
114 8. The MetaManifest must ultimately be GnuPG-signed.
115 8.1. For the initial implementation, the same key as used for snapshot
116 tarball signing is sufficient.
117 8.2. For the future, the key used for fully automated signing by infra
118 should not be on the same keyring as developer keys. See [GLEPxx+3
119 for further notes].
120
121 The above does not conflict the proposal contained in GLEP33, which
122 restructure eclasses to include subdirectories and Manifest files, as
123 the Manifest rules above still provide indirect verification for all
124 files after the GLEP33 restructuring if it comes to pass.
125
126 If other Manifests are added (such as per-category, or protecting
127 versioned eclases), the size of the MetaManifest will be greatly
128 reduced, and this specification was written with such a possible future
129 addition in mind.
130
131 MetaManifest generation will take place as part of the existing process
132 by infrastructure that takes the contents of CVS and prepares it for
133 distribution via rsync, which includes generating metadata. In-tree
134 Manifest files are not checked at this point, as they are assumed to be
135 correct.
136
137 --------------------------------------------------------
138 Verification of one or more items from the MetaManifest:
139 --------------------------------------------------------
140 There are two times that this may happen: firstly, immediately after the
141 rsync has completed - this has the advantage that the kernel file cache
142 is hot, and checking the entire tree can be accomplished quickly.
143 Secondly, the MetaManifest should be checked during installation of a
144 package.
145
146 ----------------------------------------------------
147 Procedure for verifying an item in the MetaManifest:
148 ----------------------------------------------------
149 In the following, I've used term 'M2-verify' to note following the hash
150 verification procedures as defined by the Manifest2 format - which
151 compromise checking the file length, and that the hashes match. Which
152 filetypes may be ignored on missing is discussed in [GLEPxx+5].
153
154 1. Check the GnuPG signature on the MetaManifest against the keyring of
155 automated Gentoo keys. See [GLEPxx+3] for full details regarding
156 verification of GnuPG signatures.
157 1.1. Abort if the signature check fails.
158
159 2. Check the Timestamp header. If it is significently out of date
160 compared to the local clock or a trusted source, halt or require
161 manual intervention from the user.
162
163 3. For a verification of the tree following an rsync:
164 3.1. Build a set 'ALL' of every file covered by the rsync. (exclude
165 distfiles/, packages/, local/)
166 3.2. M2-verify every entry in the MetaManifest, descending into inferior
167 Manifests as needed. Place the relative path of every checked item
168 into a set 'COVERED'.
169 3.3. Construct the set 'UNCOVERED' by set-difference between the ALL and
170 COVERED sets.
171 3.4. For each file in the UNCOVERED set, assign a Manifest2 filetype.
172 3.5. If the filetype for any file in the UNCOVERED set requires a halt
173 on error, abort and display a suitable error.
174 3.6. Completed verification
175
176 4. If checking at the installation of a package:
177 4.1. M2-verify the entry in MetaManifest for the Manifest
178 4.2. M2-verify all relevant metadata/ contents if metadata/ is being
179 used in any way (optionally done before dependancy checking).
180 4.3. M2-verifying the contents of the Manifest.
181 4.4. Perform M2-verification of all eclasses and profiles used (both
182 directly and indirectly) by the ebuild.
183
184 Notes:
185 ======
186 1. For initial implementations, it is acceptable to check EVERY item in
187 the eclass and profiles directory, rather than tracking the exact
188 files used by every eclass (see note #2). Later implementations
189 should strive to only verify individual eclasses and profiles as
190 needed.
191 2. Tracking of exact files is of specific significance to the libtool
192 eclass, as it stores patches under eclass/ELT-patches, and as such
193 that would not be picked up by any tracing of the inherit function.
194 This may be alleviated by a later eclass and ebuild variable that
195 explicitly declares what files from the tree are used by a package.
196
197 ====================
198 Implementation Notes
199 ====================
200 For this portion of the tree-signing work, no actions are required of
201 the individual Gentoo developers. They will continue to develop and
202 commit as they do presently, and the MetaManifest is added by
203 Infrastructure during the tree generation process, and distributed to
204 users.
205
206 --------------------------------------------
207 MetaManifest and the new Manifest2 filetypes
208 --------------------------------------------
209 While [GLEPxx+5] describes the addition of new filetypes, these are NOT
210 needed for implementation of the MetaManifest proposal. Without the new
211 filetypes, all entries in the MetaManifest would be of type 'MISC'.
212
213 ----------------------------------------------------
214 Timestamps & Additional distribution of MetaManifest
215 ----------------------------------------------------
216 As discussed by [C08a,C08b], malicious third-party mirrors may use the
217 principles of exclusion and replay to deny an update to clients, while
218 at the same time recording the identity of clients to attack.
219
220 This should be guarded against by including a timestamp in the header of
221 the MetaManifest, as well as distributing the latest MetaManifests by a
222 trusted channel.
223
224 On all rsync mirrors directly maintained by the Gentoo infrastructure,
225 and not on community mirrors, there should be a new module
226 'gentoo-portage-metamanifests'. Within this module, all MetaManifests
227 for a recent time frame (eg one week) should be kept, named as
228 "MetaManifest.$TS", where $TS is the timestamp from inside the file.
229 The most recent MetaManifest should always be symlinked as
230 MetaManifest.current. The possibility of serving the recent
231 MetaManifests via HTTPS should also be explored to mitigate MitM
232 attacks.
233
234 The package manager should obtain MetaManifest.current and use it to
235 decide is the tree is too out of date per operation #2 of the
236 verification process. The decision about freshness should be a
237 user-configuration setting, with the ability to override.
238
239 --------------------------------
240 MetaManifest size considerations
241 --------------------------------
242 With only two levels of Manifests (per-package and top-level), every
243 rsync will cause a lot of traffic transfering the modified top-level
244 MetaManifest. To reduce this, per-category Manifests are strongly
245 recommended. Alternatively, if the distribution method efficently
246 handles small patch-like changes in an existing file, using an
247 uncompressed MetaManifest may be acceptable (this would primarily be
248 distributed version control systems). Other suggestions in reducing this
249 traffic are welcomed.
250
251 =======================
252 Backwards Compatibility
253 =======================
254 - There are no backwards compatibility issues, as old versions of
255 Portage do not look for a Manifest file at the top level of the tree.
256 - Manifest2-aware versions of Portage ignore all entries that they are
257 not certain how to handle. Enabling headers and PGP signing to be
258 conducted easily.
259
260 ======
261 Thanks
262 ======
263 I'd like to thank the following people for input on this GLEP.
264 - Patrick Lauer (patrick): Prodding me to get all of the tree-signing
265 work finished, and helping to edit.
266 - Ciaran McCreesh (ciaranm): Paludis Manifest2
267 - Brian Harring (ferringb): pkgcore Manifest2
268 - Marius Mauch (genone) & Zac Medico (zmedico): Portage Manifest2
269 - Ned Ludd (solar) - Security concept review
270
271 ==========
272 References
273 ==========
274
275 [C08a] Cappos, J et al. (2008). "Package Management Security".
276 University of Arizona Technical Report TR08-02. Available online
277 from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf
278 [C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
279 Available online at:
280 http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
281
282 =========
283 Copyright
284 =========
285 Copyright (c) 2006 by Robin Hugh Johnson. This material may be
286 distributed only subject to the terms and conditions set forth in the
287 Open Publication License, v1.0.
288
289 vim: tw=72 ts=2 expandtab:

  ViewVC Help
Powered by ViewVC 1.1.20