/[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.3 - (show annotations) (download)
Wed Jan 13 03:26:53 2010 UTC (4 years, 7 months ago) by robbat2
Branch: MAIN
Changes since 1.2: +9 -9 lines
File MIME type: text/plain
Fix spelling in treesigning gleps.

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

  ViewVC Help
Powered by ViewVC 1.1.20