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