| 1 |
cardoe |
1.1 |
GLEP: 57 |
| 2 |
|
|
Title: Security of distribution of Gentoo software - Overview |
| 3 |
robbat2 |
1.2 |
Version: $Revision: 1.1 $ |
| 4 |
|
|
Last-Modified: $Date: 2008/10/21 23:30:47 $ |
| 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 |
|
|
Updated: May 2006, October 2006, Novemeber 2007, June 2008, July 2008, October 2008 |
| 11 |
robbat2 |
1.2 |
Post-History: |
| 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. |
| 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 (eg: Compromise a country-local rsync mirror, |
| 58 |
|
|
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 malicous 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 |
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. |
| 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 |
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. |
| 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 |
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. |
| 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 sufficent 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) 2006 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