/[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.5 - (show annotations) (download)
Sun Feb 7 16:24:17 2010 UTC (4 years, 7 months ago) by robbat2
Branch: MAIN
Changes since 1.4: +4 -2 lines
File MIME type: text/plain
Fix up missing references to the unfinished tree-signing gleps that handle the GnuPG side and the developer process side.

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

  ViewVC Help
Powered by ViewVC 1.1.20