/[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 - (hide annotations) (download)
Sun Feb 7 16:24:17 2010 UTC (4 years, 8 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 cardoe 1.1 GLEP: 57
2     Title: Security of distribution of Gentoo software - Overview
3 robbat2 1.5 Version: $Revision: 1.4 $
4     Last-Modified: $Date: 2010/01/29 09:04:17 $
5 cardoe 1.1 Author: Robin Hugh Johnson <robbat2@gentoo.org>
6 robbat2 1.4 Status: Final
7 cardoe 1.1 Type: Informational
8     Content-Type: text/x-rst
9     Created: November 2005
10 robbat2 1.3 Updated: May 2006, October 2006, November 2007, June 2008, July 2008, October 2008, January 2010
11     Post-History: December 2009
12 robbat2 1.4 Approved: 18 January 2010
13 cardoe 1.1
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 robbat2 1.3 existing infrastructure (e.g.: Compromise a country-local rsync
59     mirror, and totally replace a package and it's Manifest).
60 cardoe 1.1
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 robbat2 1.3 (including malicious mirrors) must be considered.
99 cardoe 1.1
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 robbat2 1.2 Both processes need their security improved. In [#GLEPxx+2] we will discuss
111 cardoe 1.1 how to improve the security of the first process. The relatively
112     speaking simpler process of file distribution will be described in
113 robbat2 1.2 [#GLEP58]. Since it can be implemented without having to change the
114 cardoe 1.1 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 robbat2 1.2 vigilance. This is further discussed in [#GLEPxx+2].
156 cardoe 1.1
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 robbat2 1.2 [#GLEP58]. As this process has the most to gain in security, and the
171 cardoe 1.1 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 robbat2 1.3 tree is not sufficient to prevent all attacks.
310 cardoe 1.1 [ 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 robbat2 1.5 [#GLEPxx+2] Future GLEP on Developer Process security.
341     [#GLEPxx+3] Future GLEP on GnuPG Policies and Handling.
342 cardoe 1.1
343     Copyright
344     =========
345 robbat2 1.3 Copyright (c) 2005-2010 by Robin Hugh Johnson. This material may be
346 cardoe 1.1 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