| 1 |
GLEP: 57
|
| 2 |
Title: Security of distribution of Gentoo software - Overview
|
| 3 |
Version: $Revision: 1.5 $
|
| 4 |
Last-Modified: $Date: 2010/02/07 16:24:17 $
|
| 5 |
Author: Robin Hugh Johnson <robbat2@gentoo.org>
|
| 6 |
Status: Final
|
| 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 |
Approved: 18 January 2010
|
| 13 |
|
| 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 |
existing infrastructure (e.g.: Compromise a country-local rsync
|
| 59 |
mirror, and totally replace a package and it's Manifest).
|
| 60 |
|
| 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 |
(including malicious mirrors) must be considered.
|
| 99 |
|
| 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 |
Both processes need their security improved. In [GLEPxx2] we will discuss
|
| 111 |
how to improve the security of the first process. The relatively
|
| 112 |
speaking simpler process of file distribution will be described in
|
| 113 |
[GLEP58]. Since it can be implemented without having to change the
|
| 114 |
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 |
vigilance. This is further discussed in [GLEPxx2].
|
| 156 |
|
| 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 |
[GLEP58]. As this process has the most to gain in security, and the
|
| 171 |
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 |
tree is not sufficient to prevent all attacks.
|
| 310 |
[ 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 |
|
| 338 |
.. [C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
|
| 339 |
Available online at:
|
| 340 |
http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
|
| 341 |
|
| 342 |
.. [GLEP58] Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
|
| 343 |
http://www.gentoo.org/proj/en/glep/glep-0058.html
|
| 344 |
|
| 345 |
.. [GLEPxx2] Future GLEP on Developer Process security.
|
| 346 |
|
| 347 |
.. [GLEPxx3] Future GLEP on GnuPG Policies and Handling.
|
| 348 |
|
| 349 |
Copyright
|
| 350 |
=========
|
| 351 |
Copyright (c) 2005-2010 by Robin Hugh Johnson. This material may be
|
| 352 |
distributed only subject to the terms and conditions set forth in the
|
| 353 |
Open Publication License, v1.0.
|
| 354 |
|
| 355 |
.. vim: tw=72 ts=2 expandtab:
|
Parent Directory
| 
Revision Log