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: |