Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Portage and Update Security
Date: Mon, 16 Mar 2015 01:23:19
Message-Id: 20150315182313.2d1f009f.dolsen@gentoo.org
In Reply to: Re: [gentoo-portage-dev] Portage and Update Security by Vladimir Diaz
1 On Sun, 15 Mar 2015 18:27:06 -0400
2 Vladimir Diaz <vladimir.v.diaz@×××××.com> wrote:
3
4 > On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <antarus@g.o>
5 > wrote:
6 >
7 > > On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz
8 > > <vladimir.v.diaz@×××××.com> wrote:
9 > >
10 > >> Hi,
11 > >>
12 > >> I am a developer in the Secure Systems Lab at NYU. Our lab has
13 > >> collaborated with popular software update systems in the
14 > >> open-source community, including APT, yum, and YaST, to address
15 > >> security problems. More recently, we have been working on a
16 > >> flexible security framework co-developed with the Tor project that
17 > >> can be easily added to software updaters to transparently solve
18 > >> many of the known security flaws we have uncovered in software
19 > >> updaters. We would like to work with The Portage Development
20 > >> Project to better secure the Portage distribution system.
21 > >>
22 > >
23 > > I'm not familiar with your work on APT, do you have a link?
24 > >
25 >
26 > There are LWN.net <http://lwn.net/Articles/327847/> and ;login:
27 > <https://www.usenix.org/legacy/publications/login/2009-02/openpdfs/samuel.pdf>
28 > articles, and an Ubuntu bug report
29 > <https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>, that
30 > discuss some of the architectural and security improvements adopted
31 > (at the time) by APT and other package managers. The A Look In the
32 > Mirror: Attacks on Package Managers
33 > <https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf> paper
34 > <https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>goes into
35 > more detail.
36 >
37 >
38 > >
39 > >
40 > >> TUF
41 > >> <https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems>
42 > >> (The Update Framework) is a library that can be added to an
43 > >> existing software update system and is designed to update files in
44 > >> a more secure manner. Many software updaters verify software
45 > >> updates with cryptographic signatures and hash functions, but they
46 > >> typically fail to protect against malicious attacks that target
47 > >> the metadata and update files presented to clients. A rollback
48 > >> attack is one such example, where an attacker tricks a client into
49 > >> installing older files than those the client has already seen
50 > >> (these older files may be vulnerable versions that have since been
51 > >> fixed). A full list of attacks and weaknesses the framework is
52 > >> designed to address is provided here
53 > >> <https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security> .
54 > >>
55 > >> Our website <http://theupdateframework.com/index.html> includes
56 > >> more information about TUF, including: papers
57 > >> <https://github.com/theupdateframework/tuf/tree/develop/docs/papers>
58 > >> and a specification
59 > >> <https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt>.
60 > >> If you want to see how an existing project integrates TUF, there
61 > >> is a standards track proposal
62 > >> <https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract>
63 > >> to the Python community that you can review. A more rigorous
64 > >> proposal that requires more administrative work on the repository,
65 > >> but provides more security protections, is also available
66 > >> <https://www.python.org/dev/peps/pep-0480/>.
67 > >>
68 > >> We were thinking of submitting a pull request that shows how such
69 > >> an integration would work. So there hopefully won't be much leg
70 > >> work on your end apart from deciding how the system should be
71 > >> configured (key storage, roles, etc.).
72 > >>
73 > >
74 > >> Would a pull request be of interest? Is there anything you'd like
75 > >> us to say more about?
76 > >>
77 > >
78 > > I guess I am less concerned with adding support to portage (which
79 > > as you note, is likely fairly straightforward) vs actually
80 > > generating, publishing, and signing the metadata; which you would
81 > > have convince the infrastructure team to do.
82 > >
83 >
84 > How can we contact the infrastructure team? I searched the Gentoo
85 > mailing list page <https://www.gentoo.org/main/en/lists.xml> and found
86 > "gentoo-infrastructure", but it is a restricted list.
87 >
88 > >
89 > >
90 > >> Thanks,
91 > >> Vlad
92 > >>
93 > >> P.S.
94 > >> There are Informational <http://wiki.gentoo.org/wiki/GLEP:57> and
95 > >> Standards Track <http://wiki.gentoo.org/wiki/GLEP:58> GLEPs that
96 > >> reference our work and the security issues that our project
97 > >> addresses, but there hasn't been much recent activity on these
98 > >> proposals.
99 > >>
100 > >
101 > > FWIW, I would rather adopt the standard than continue with a gentoo
102 > > specific thing; but I'm not the guy who is going to implement it. I
103 > > would recommend talking to the GLEP author (robbat2@g.o)
104 > >
105 >
106 > Thank you. We'll contact the GLEP author to discuss the standard.
107 >
108 >
109 >
110
111 robbat2 is the infra lead, so that is the correct person to contact.
112
113
114
115 I've held off replying so far because I'm trying to get some time to
116 figure out your system. I'm not sure yet whether your system will fit
117 the plans and structure for our main tree.
118
119 git now has signed commit support, which was a request gentoo had made
120 long ago in order for our migration to git from cvs. Until recent
121 versions it was not easy to re-verify a signed commit. We have have
122 signed Manifest support in the system for some time now, but have not
123 been enforcing it fully up till now. We have a new project called
124 gentoo-keys [1] which is a gpg key management app and libs to handle the
125 various gpg keys from devs, release media, and others. We are in the
126 process of getting our devs to create/update their gpg keys to meet the
127 new minimum spec (GLEP 63). I am just starting to integrate gkeys libs
128 use into portage to verify the package Manifests which is similar to
129 what you do. With the git migration, commits must be signed, but
130 will be using a "thin" manifest rather than the full one. Instead we
131 will be enforcing the --sign option for git push (recently added to
132 git). That will use gkeys to verify the pushed content via a hook and
133 replacement gpg command that uses gkeys.
134
135 So the main git repo will be secured similar to what I've gleaned from
136 your code so far. The main syncing of the tree for users will be done
137 via rsync still, but for that the full Manifest files will be
138 (re)generated as needed and signed with an infra controlled key.
139 Normal users system will be able to verify those Manifests. There is
140 also optional versions of the tree which are signed in total
141 (emerge-webrsync) and verify-able.
142
143 As has been pointed out the other thread [3] which was started just
144 before this one. We are in a different place than what the binary
145 distributions are in terms of repositories. Not all attack vectors
146 your code is meant to address applies to our situation.
147
148 I do think your repository manifest was something that robbat2 had
149 talked about implementing for overlay maintainers as an option for
150 layman to be able to verify updates to the overlay repos. It would
151 likely have to be generated from a VCS hook which runs when commits are
152 made/pushed.
153
154
155 I'd love to hear how your code can fit in to the Gentoo system.
156
157 links:
158
159 [1] http://gitweb.gentoo.org/proj/gentoo-keys.git/
160
161 gkeys article in LWN: http://lwn.net/Articles/634777/
162
163 [3]
164 http://archives.gentoo.org/gentoo-portage-dev/message/bda425ee6c676ec7a6b3c9500a9b00bf
165 --
166 Brian Dolbec <dolsen>

Replies

Subject Author
Re: [gentoo-portage-dev] Portage and Update Security Vladimir Diaz <vladimir.v.diaz@×××××.com>