| 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: |
Parent Directory
| 
Revision Log