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 |
> |