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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.3 - (hide annotations) (download)
Wed Jan 13 03:26:53 2010 UTC (9 years ago) by robbat2
Branch: MAIN
Changes since 1.2: +9 -9 lines
File MIME type: text/plain
Fix spelling in treesigning gleps.

1 cardoe 1.1 GLEP: 57
2     Title: Security of distribution of Gentoo software - Overview
3 robbat2 1.3 Version: $Revision: 1.2 $
4     Last-Modified: $Date: 2008/10/28 07:45:07 $
5 cardoe 1.1 Author: Robin Hugh Johnson <robbat2@gentoo.org>
6     Status: Draft
7     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 cardoe 1.1
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.
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.
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.
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.
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:
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 robbat2 1.3 existing infrastructure (e.g.: Compromise a country-local rsync
58     mirror, and totally replace a package and it's Manifest).
59 cardoe 1.1
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.
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.
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.
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 robbat2 1.3 (including malicious mirrors) must be considered.
98 cardoe 1.1
99     Processes
100     ---------
101     There are two major processes in the distribution of Gentoo, where
102     security needs to be implemented:
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).
109 robbat2 1.2 Both processes need their security improved. In [#GLEPxx+2] we will discuss
110 cardoe 1.1 how to improve the security of the first process. The relatively
111     speaking simpler process of file distribution will be described in
112 robbat2 1.2 [#GLEP58]. Since it can be implemented without having to change the
113 cardoe 1.1 workflow and behaviour of developers we hope to get it done in a
114     reasonably short timeframe.
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.
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.
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.
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.
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 robbat2 1.2 vigilance. This is further discussed in [#GLEPxx+2].
155 cardoe 1.1
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.
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 robbat2 1.2 [#GLEP58]. As this process has the most to gain in security, and the
170 cardoe 1.1 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.
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.
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.
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.
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 ]
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 ]
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 ]
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 ]
214     2003-04, gentoo-core mailing list, "New Digests and Signing -- Attempted Explanation"
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.
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.
224     2003-12-02, gentoo-core mailing list, "Report: rsync1.it.gentoo.org compromised"
226     2003-12-03, gentoo-core mailing list, "Signing of ebuilds"
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.
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 ]
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
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 ]
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.
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 ]
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.
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.
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 ]
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 ]
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 ]
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 ]
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 ]
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).
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 robbat2 1.3 tree is not sufficient to prevent all attacks.
309 cardoe 1.1 [ http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542 ]
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 ]
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 ]
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).
330     References
331     ==========
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/
340     Copyright
341     =========
342 robbat2 1.3 Copyright (c) 2005-2010 by Robin Hugh Johnson. This material may be
343 cardoe 1.1 distributed only subject to the terms and conditions set forth in the
344     Open Publication License, v1.0.
346     vim: tw=72 ts=2 expandtab:

  ViewVC Help
Powered by ViewVC 1.1.20