1 |
On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <antarus@g.o> wrote: |
2 |
|
3 |
> On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz <vladimir.v.diaz@×××××.com> |
4 |
> wrote: |
5 |
> |
6 |
>> Hi, |
7 |
>> |
8 |
>> I am a developer in the Secure Systems Lab at NYU. Our lab has |
9 |
>> collaborated with popular software update systems in the open-source |
10 |
>> community, including APT, yum, and YaST, to address security problems. |
11 |
>> More recently, we have been working on a flexible security framework |
12 |
>> co-developed with the Tor project that can be easily added to software |
13 |
>> updaters to transparently solve many of the known security flaws we have |
14 |
>> uncovered in software updaters. We would like to work with The Portage |
15 |
>> Development Project to better secure the Portage distribution system. |
16 |
>> |
17 |
> |
18 |
> I'm not familiar with your work on APT, do you have a link? |
19 |
> |
20 |
|
21 |
There are LWN.net <http://lwn.net/Articles/327847/> and ;login: |
22 |
<https://www.usenix.org/legacy/publications/login/2009-02/openpdfs/samuel.pdf> |
23 |
articles, and an Ubuntu bug report |
24 |
<https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>, that discuss |
25 |
some of the architectural and security improvements adopted (at the time) |
26 |
by APT and other package managers. The A Look In the Mirror: Attacks on |
27 |
Package Managers |
28 |
<https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf> paper |
29 |
<https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>goes into more |
30 |
detail. |
31 |
|
32 |
|
33 |
> |
34 |
> |
35 |
>> TUF |
36 |
>> <https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems> |
37 |
>> (The Update Framework) is a library that can be added to an existing |
38 |
>> software update system and is designed to update files in a more secure |
39 |
>> manner. Many software updaters verify software updates with cryptographic |
40 |
>> signatures and hash functions, but they typically fail to protect against |
41 |
>> malicious attacks that target the metadata and update files presented to |
42 |
>> clients. A rollback attack is one such example, where an attacker tricks a |
43 |
>> client into installing older files than those the client has already seen |
44 |
>> (these older files may be vulnerable versions that have since been fixed). |
45 |
>> A full list of attacks and weaknesses the framework is designed to address |
46 |
>> is provided here |
47 |
>> <https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security> |
48 |
>> . |
49 |
>> |
50 |
>> Our website <http://theupdateframework.com/index.html> includes more |
51 |
>> information about TUF, including: papers |
52 |
>> <https://github.com/theupdateframework/tuf/tree/develop/docs/papers> and |
53 |
>> a specification |
54 |
>> <https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt>. |
55 |
>> If you want to see how an existing project integrates TUF, there is a |
56 |
>> standards track proposal |
57 |
>> <https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract> |
58 |
>> to the Python community that you can review. A more rigorous proposal that |
59 |
>> requires more administrative work on the repository, but provides more |
60 |
>> security protections, is also available |
61 |
>> <https://www.python.org/dev/peps/pep-0480/>. |
62 |
>> |
63 |
>> We were thinking of submitting a pull request that shows how such an |
64 |
>> integration would work. So there hopefully won't be much leg work on your |
65 |
>> end apart from deciding how the system should be configured (key storage, |
66 |
>> roles, etc.). |
67 |
>> |
68 |
> |
69 |
>> Would a pull request be of interest? Is there anything you'd like us to |
70 |
>> say more about? |
71 |
>> |
72 |
> |
73 |
> I guess I am less concerned with adding support to portage (which as you |
74 |
> note, is likely fairly straightforward) vs actually generating, publishing, |
75 |
> and signing the metadata; which you would have convince the infrastructure |
76 |
> team to do. |
77 |
> |
78 |
|
79 |
How can we contact the infrastructure team? I searched the Gentoo mailing |
80 |
list page <https://www.gentoo.org/main/en/lists.xml> and found |
81 |
"gentoo-infrastructure", but it is a restricted list. |
82 |
|
83 |
> |
84 |
> |
85 |
>> Thanks, |
86 |
>> Vlad |
87 |
>> |
88 |
>> P.S. |
89 |
>> There are Informational <http://wiki.gentoo.org/wiki/GLEP:57> and Standards |
90 |
>> Track <http://wiki.gentoo.org/wiki/GLEP:58> GLEPs that reference our |
91 |
>> work and the security issues that our project addresses, but there hasn't |
92 |
>> been much recent activity on these proposals. |
93 |
>> |
94 |
> |
95 |
> FWIW, I would rather adopt the standard than continue with a gentoo |
96 |
> specific thing; but I'm not the guy who is going to implement it. I would |
97 |
> recommend talking to the GLEP author (robbat2@g.o) |
98 |
> |
99 |
|
100 |
Thank you. We'll contact the GLEP author to discuss the standard. |
101 |
|
102 |
|
103 |
|
104 |
> |
105 |
> -A |
106 |
> |
107 |
> |
108 |
>> |
109 |
>> |
110 |
>> -- |
111 |
>> vladimir.v.diaz@×××××.com |
112 |
>> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 |
113 |
>> -- |
114 |
>> |
115 |
> |
116 |
> |