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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations) (download)
Tue Oct 21 23:30:47 2008 UTC (6 years, 2 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: 57
2 Title: Security of distribution of Gentoo software - Overview
3 Version: $Revision: 1.13 $
4 Last-Modified: $Date: 2008/10/09 23:23:12 $
5 Author: Robin Hugh Johnson <robbat2@gentoo.org>
6 Status: Draft
7 Type: Informational
8 Content-Type: text/x-rst
9 Created: November 2005
10 Updated: May 2006, October 2006, Novemeber 2007, June 2008, July 2008, October 2008
11
12 Abstract
13 ========
14 This is the first in a series of 4 GLEPs. It aims to define the actors
15 and problems in the Gentoo software distribution process, with a strong
16 emphasis on security. The concepts thus developed, will then be used in
17 the following GLEPs to describe a comprehensive security solution for
18 this distribution process that prevents trivial attacks and increases
19 the difficulty on more complex attacks.
20
21 Motivation
22 ==========
23 Since at mid-2002 (see endnote: "History of tree-signing in Gentoo"),
24 many discussions have taken place on the gentoo-dev mailing list and in
25 many other places to design and implement a security strategy for the
26 distribution of files by the Gentoo project.
27
28 Usually the goal of such proposals was and is to be able to securely
29 identify the data provided by Gentoo and prevent third parties (like a
30 compromised mirror) from delivering harmful data (be it as modified
31 ebuilds, executable shell code or any other form) to the users of the
32 Gentoo MetaDistribution.
33
34 These strategies can neither prevent a malicious or compromised upstream
35 from injecting "bad" programs, nor can they stop a rogue developer from
36 committing malicious ebuilds. What they can do is to reduce the attack
37 vectors so that for example a compromised mirror will be detected and no
38 tainted data will be executed on user's systems.
39
40 Gentoo's software distribution system as it presently stands, contains a
41 number of security shortcomings. The last discussion on the gentoo-dev
42 mailing list [http://thread.gmane.org/gmane.linux.gentoo.devel/38363]
43 contains a good overview of most of the issues. Summarized here:
44
45 - Unverifiable executable code distributed:
46 The most obvious instance are eclasses, but there are many other bits
47 of the tree that are not signed at all right now. Modifying that data
48 is trivial.
49 - Shortcomings of existing Manifest verification
50 A lack and enforcement of policies, combined with suboptimal support
51 in portage, makes it trivial to modify or replace the existing
52 Manifests.
53 - Vulnerability of existing infrastructure to attacks.
54 The previous two items make it possible for a skilled attacker to
55 design an attack and then execute it against specific portions of
56 existing infrastructure (eg: Compromise a country-local rsync mirror,
57 and totally replace a package and it's Manifest).
58
59 Specification
60 =============
61 Security is not something that can be considered in isolation. It is
62 both an ongoing holistic process and lessons learnt by examining
63 previous shortcomings.
64
65 System Elements
66 ---------------
67 There are a few entities to be considered:
68 - Upstream. The people who provide the program(s) or data we wish to
69 distribute.
70 - Gentoo Developers. The people that package and test the things
71 provided by Upstream.
72 - Gentoo Infrastructure. The people and hardware that allow the revision
73 control of metadata and distribution of the data and metadata provided
74 by Developers and Upstream.
75 - Gentoo Mirrors. Hardware provided by external contributors that is not
76 or only marginally controlled by Gentoo Infrastructure. Needed to
77 achieve the scalability and performance needed for the substantial
78 Gentoo user base.
79 - Gentoo Users. The people that use the Gentoo MetaDistribution.
80
81 The data described here is usually programs and data files provided by
82 upstream; as this is a rather large amount of data it is usually
83 distributed over http or ftp from Gentoo Mirrors. This data is usually
84 labeled as "distfiles". Metadata is all information describing how to
85 manipulate that data - it is usually called "The Tree" or "The Portage
86 Tree", consists of many ebuilds, eclasses and supporting files and is
87 usually distributed over rsync. The central rsync servers are controlled
88 by Gentoo Infrastructure, but many third-party rsync mirrors exist that
89 help to reduce the load on those central servers. These extra mirrors
90 are not maintained by Gentoo Infrastructure.
91
92 Attacks may be conducted against any of these entities. Obviously
93 direct attacks against Upstream and Users are outside of the scope of
94 this series of GLEPs as they are not in any way controlled or
95 controllable by Gentoo - however attacks using Gentoo as a conduit
96 (including malicous mirrors) must be considered.
97
98 Processes
99 ---------
100 There are two major processes in the distribution of Gentoo, where
101 security needs to be implemented:
102
103 - Developer commits to version control systems controlled by
104 Infrastructure.
105 - Tree and distfile distribution from Infrastructure to Users, via the
106 mirrors (this includes both HTTP and rsync distribution).
107
108 Both processes need their security improved. In [GLEPxx+2] we will discuss
109 how to improve the security of the first process. The relatively
110 speaking simpler process of file distribution will be described in
111 [GLEPxx+1]. Since it can be implemented without having to change the
112 workflow and behaviour of developers we hope to get it done in a
113 reasonably short timeframe.
114
115 Attacks against Processes
116 -------------------------
117 Attacks against the process #1 may be as complex as a malicious or
118 compromised developer (stolen SSH keys, rooted systems), or as simple as
119 a patch from a user that does a little more than it claims, and is not
120 adequately reviewed.
121
122 Attacks against the process #2 may be as simple as a single rooted
123 mirror, distributing a modified tree to the users of that mirror - or
124 some alteration of upstream sources. These attacks have a low cost and
125 are very hard to discover unless all distributed data is transparently
126 signed.
127
128 A simple example of such an attack and a partial solution for eclasses
129 is presented in [ http://thread.gmane.org/gmane.linux.gentoo.devel/24677
130 ]. It shows quite well that any non-Gentoo controlled rsync mirror can
131 modify executable code; as much of this code is per default run as root
132 a malicious mirror could compromise hundreds of systems per day - if
133 cloaked well enough, such an attack could run for weeks before being
134 noticed. As there are no effective safeguards right now users are left
135 with the choice of either syncing from the sometimes slow or even
136 unresponsive Gentoo-controlled rsync mirrors or risk being compromised
137 by syncing from one of the community-provided mirrors. We will show that
138 protection against this class of attacks is very easy to implement with
139 little added cost.
140
141 At the level of mirrors, addition of malicious content is not the only
142 attack. As discussed by Cappos et al [C08a,C08b], an attacker may use
143 exclusion and replay attacks, possibly only on a specific subset of
144 user to extend the window of opportunity on another exploit.
145
146 Security for Processes
147 ------------------------
148 Protection for process #1 can never be complete (without major
149 modifications to our development process), as a malicious developer is
150 fully authorized to provide materials for distribution. Partial
151 protection can be gained by Portage and Infrastructure changes, but the
152 real improvements needed are developer education and continued
153 vigilance. This is further discussed in [GLEPxx+2].
154
155 This security is still limited in scope - protection against compromised
156 developers is very expensive, and even complex systems like peer review
157 / multiple signatures can be broken by colluding developers. There are many
158 issues, be it social or technical, that increase the cost of such
159 measures a lot while only providing marginal security gains. Any
160 implementation proposal must be carefully analysed to find the best
161 security to developer hassle ratio.
162
163 Protection for process #2 is a different matter entirely. While it also
164 cannot be complete (as the User may be attacked directly), we can ensure
165 that Gentoo infrastructure and the mirrors are not a weak point. This
166 objective is actually much closer than it seems already - most of the
167 work has been completed for other things!. This is further discussed in
168 [GLEP58]. As this process has the most to gain in security, and the
169 most immediate impact, it should be implemented before or at the same
170 time as any changes to process #1. Security at this layer is already
171 available in the signed daily snapshots, but we can extend it to cover
172 the rsync mirrors as well.
173
174 Requirements pertaining to and management of keys (OpenPGP or otherwise)
175 is an issue that affects both processes, and is broken out into a
176 separate GLEP due to the technical complexity of the subject.
177 This deals with everything including: types of keys to use; usage
178 guidelines; procedures for managing signatures and trust for keys,
179 including cases of lost (destroyed) and stolen (or otherwise turned
180 malicious) keys.
181
182 Backwards Compatibility
183 =======================
184 As an informational GLEP, this document has no direct impact on
185 backwards compatibility. However the related in-depth documents may
186 delve further into any issues of backwards compatibility.
187
188 Endnote: History of tree-signing in Gentoo
189 ==========================================
190 This is a brief review of every previous tree-signing discussion, the
191 stuff before 2003-04-03 was very hard to come by, so I apologize if I've
192 missed a discussion (I would like to hear about it). I think there was
193 a very early private discussion with drobbins in 2001, as it's vaguely
194 referenced, but I can't find it anywhere.
195
196 2002-06-06, gentoo-dev mailing list, users first ask about signing of
197 ebuilds:
198 [ http://thread.gmane.org/gmane.linux.gentoo.devel/1950 ]
199
200 2003-01-13, gentoo-dev mailing list, "Re: Verifying portage is from
201 Gentoo" - Paul de Vrieze (pauldv):
202 [ http://thread.gmane.org/gmane.linux.gentoo.devel/6619/focus=6619 ]
203
204 2003-04, GWN articles announcing tree signing:
205 [ http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3 ]
206 [ http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2 ]
207
208 2003-04, gentoo-security mailing list, "The state of ebuild signing
209 in portage" - Joshua Brindle (method), the first suggestion of signed Manifests,
210 but also an unusual key-trust model:
211 [ http://marc.theaimsgroup.com/?l=gentoo-security&m=105073449619892&w=2 ]
212
213 2003-04, gentoo-core mailing list, "New Digests and Signing -- Attempted Explanation"
214
215 2003-06, gentoo-core mailing list, "A quick guide to GPG and key
216 signing." - This overview was one of the first to help developers see
217 how to use their devs, and was mainly intended for keysigning meetups.
218
219 2003-08-09, gentoo-core mailing list, "Ebuild signing" - status query,
220 with an not very positive response, delayed by Nick Jones (carpaski)
221 getting rooted and a safe cleanup taking a long time to affect.
222
223 2003-12-02, gentoo-core mailing list, "Report: rsync1.it.gentoo.org compromised"
224
225 2003-12-03, gentoo-core mailing list, "Signing of ebuilds"
226
227 2003-12-07, gentoo-core mailing list, "gpg signing of Manifests", thread
228 includes the first GnuPG signing prototype code, by Robin H. Johnson
229 (robbat2). Andrew Cowie (rac) also produces a proof-of-concept around
230 this time.
231
232 2004-03-23, gentoo-dev mailing list, "2004.1 will not include a secure
233 portage" - Kurt Lieber (klieber). Signing is nowhere near ready for
234 2004.1 release, and it is realized that it there is insufficient traction
235 and the problem is very large. Many arguments about the checking and
236 verification side. First warning signs that MD5 might be broken in the
237 near future.
238 [ http://thread.gmane.org/gmane.linux.gentoo.devel/16876 ]
239
240 2004-03-25, gentoo-dev mailing list, "Redux: 2004.1 will not include a
241 secure portage" - Robin H. Johnson (robbat2). Yet another proposal,
242 summarizing the points of the previous thread and this time trying to
243 track the various weaknesses.
244 http://marc.theaimsgroup.com/?l=gentoo-dev&m=108017986400698&w=2
245
246 2004-05-31, Gentoo managers meeting, portage team reports that
247 FEATURES=sign is now available, but large questions still exist over
248 verification policies and procedures, as well as handing of keys.
249 [ http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt ]
250
251 2005-01-17, gentoo-core mailing list, "Global objective for 2005 :
252 portage signing". Thierry Carrez (koon) suggests that more go into
253 tree-signing work. Problems at the time later in the thread show that
254 the upstream gpg-agent is not ready, amongst other minor implementation
255 issues.
256
257 2005-02-20, gentoo-dev mailing list, "post-LWE 2005" - Brian Harring
258 (ferringb). A discussion on the ongoing lack of signing, and that
259 eclasses and profiles need to be signed as well, but this seems to be
260 hanging on GLEP33 in the meantime.
261 [ http://thread.gmane.org/gmane.linux.gentoo.devel/25556/focus=25596 ]
262
263 2005-03-08, gentoo-core mailing list, "gpg manifest signing stats".
264 Informal statistics show that 26% of packages in the tree include a
265 signed Manifest. Questions are raised regarding key types, and key
266 policies.
267
268 2005-11-16, gentoo-core mailing list, "Gentoo key signing practices and
269 official Gentoo keyring". A discussion of key handling and other
270 outstanding issues, also mentioning partial Manifests, as well as a
271 comparision between the signing procedures used in Slackware, Debian and
272 RPM-based distros.
273
274 2005-11-19, gentoo-portage-dev mailing list, "Manifest signing" - Robin
275 H. Johnson (robbat2) follows up the previous -core posting, discussion
276 implementation issues.
277 [ http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1401 ]
278
279 2006-05-18, gentoo-dev mailing list, "Signing everything, for fun and for
280 profit" - Patrick Lauer (bonsaikitten). Later brings up that Manifest2 is needed for
281 getting everything right.
282 [ http://thread.gmane.org/gmane.linux.gentoo.devel/38363 ]
283
284 2006-05-19, gentoo-dev mailing list, "Re: Signing everything, for fun and for
285 profit" - Robin H. Johnson (robbat2). An introduction into some of the
286 OpenPGP standard, with a focus on how it affects file signing, key
287 signing, management of keys, and revocation.
288 [ http://thread.gmane.org/gmane.linux.gentoo.devel/38363/focus=38371 ]
289
290 2007-04-11, gentoo-dev mailing list, "Re: *DEVELOPMENT* mail list,
291 right?" - Robin H. Johnson (robbat2). A progress report on these very
292 GLEPs.
293 [ http://thread.gmane.org/gmane.linux.gentoo.devel/47752/focus=47908 ]
294
295 2007-07-02, gentoo-dev mailing list, "Re: Re: Nominations open for the
296 Gentoo Council 2007/08" - Robin H. Johnson (robbat2). Another progress
297 report.
298 [ http://thread.gmane.org/gmane.linux.gentoo.devel/50029/focus=50043 ]
299
300 2007-11-30, portage-dev alias, "Manifest2 and Tree-signing" - Robin H.
301 Johnson (robbat2). First review thread for these GLEPs, many suggestions
302 from Marius Mauch (genone).
303
304 2008-04-03, gentoo-dev mailing list, "Re: Monthly Gentoo Council
305 Reminder for April" - Ciaran McCreesh (ciaranm). A thread in which
306 Ciaran reminds everybody that simply making all the developers sign the
307 tree is not sufficent to prevent all attacks.
308 [ http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542 ]
309
310 2008-07-01, gentoo-portage-dev mailing list, "proto-GLEPS for
311 Tree-signing" - Robin H. Johnson (robbat2). Thread looking for review
312 input from Portage developers.
313 [ http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2686 ]
314
315 2008-07-12, gentoo-portage-dev mailing list, "proto-GLEPS for
316 Tree-signing, take 2" - Robin H. Johnson (robbat2). Integration of
317 changes from previous review, and a prototype for the signing code.
318 zmedico also posts a patch for a verification prototype.
319 [ http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709 ]
320
321 Thanks
322 ======
323 I'd like to thank Patrick Lauer (bonsaikitten) for prodding me
324 to keep working on the tree-signing project, as well helping with
325 spelling, grammar, research (esp. tracking down every possible
326 vulnerability that has been mentioned in past discussions, and
327 integrating them in this overview).
328
329 References
330 ==========
331
332 [C08a] Cappos, J et al. (2008). "Package Management Security".
333 University of Arizona Technical Report TR08-02. Available online
334 from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf
335 [C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
336 Available online at:
337 http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
338
339 Copyright
340 =========
341 Copyright (c) 2006 by Robin Hugh Johnson. This material may be
342 distributed only subject to the terms and conditions set forth in the
343 Open Publication License, v1.0.
344
345 vim: tw=72 ts=2 expandtab:

  ViewVC Help
Powered by ViewVC 1.1.20