Gentoo Archives: gentoo-portage-dev

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