Re: [gentoo-portage-dev] Portage and Update Security

[Vladimir Diaz <vladimir.v.diaz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]

On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <antarus@gentoo.org> wrote:

> On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz <vladimir.v.diaz@gmail.com>
> wrote:
>
>> Hi,
>>
>> I am a developer in the Secure Systems Lab at NYU.  Our lab has
>> collaborated with popular software update systems in the open-source
>> community, including APT, yum, and YaST, to address security problems.
>> More recently, we have been working on a flexible security framework
>> co-developed with the Tor project that can be easily added to software
>> updaters to transparently solve many of the known security flaws we have
>> uncovered in software updaters.  We would like to work with The Portage
>> Development Project to better secure the Portage distribution system.
>>
>
> I'm not familiar with your work on APT, do you have a link?
>

There are LWN.net <http://lwn.net/Articles/327847/> and ;login:
<https://www.usenix.org/legacy/publications/login/2009-02/openpdfs/samuel.pdf>
articles, and an Ubuntu bug report
<https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>, that discuss
some of the architectural and security improvements adopted (at the time)
by APT and other package managers.  The A Look In the Mirror: Attacks on
Package Managers
<https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf> paper
<https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>goes into more
detail.


>
>
>> TUF
>> <https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems>
>> (The Update Framework) is a library that can be added to an existing
>> software update system and is designed to update files in a more secure
>> manner.  Many software updaters verify software updates with cryptographic
>> signatures and hash functions, but they typically fail to protect against
>> malicious attacks that target the metadata and update files presented to
>> clients.  A rollback attack is one such example, where an attacker tricks a
>> client into installing older files than those the client has already seen
>> (these older files may be vulnerable versions that have since been fixed).
>> A full list of attacks and weaknesses the framework is designed to address
>> is provided here
>> <https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security>
>> .
>>
>> Our website <http://theupdateframework.com/index.html> includes more
>> information about TUF, including: papers
>> <https://github.com/theupdateframework/tuf/tree/develop/docs/papers> and
>> a specification
>> <https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt>.
>> If you want to see how an existing project integrates TUF, there is a
>> standards track proposal
>> <https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract>
>> to the Python community that you can review.  A more rigorous proposal that
>> requires more administrative work on the repository, but provides more
>> security protections, is also available
>> <https://www.python.org/dev/peps/pep-0480/>.
>>
>> We were thinking of submitting a pull request that shows how such an
>> integration would work.  So there hopefully won't be much leg work on your
>> end apart from deciding how the system should be configured (key storage,
>> roles, etc.).
>>
>
>> Would a pull request be of interest?  Is there anything you'd like us to
>> say more about?
>>
>
> I guess I am less concerned with adding support to portage (which as you
> note, is likely fairly straightforward) vs actually generating, publishing,
> and signing the metadata; which you would have convince the infrastructure
> team to do.
>

How can we contact the infrastructure team?  I searched the Gentoo mailing
list page <https://www.gentoo.org/main/en/lists.xml> and found
"gentoo-infrastructure", but it is a restricted list.

>
>
>> Thanks,
>> Vlad
>>
>> P.S.
>> There are Informational <http://wiki.gentoo.org/wiki/GLEP:57> and Standards
>> Track <http://wiki.gentoo.org/wiki/GLEP:58> GLEPs that reference our
>> work and the security issues that our project addresses, but there hasn't
>> been much recent activity on these proposals.
>>
>
> FWIW, I would rather adopt the standard than continue with a gentoo
> specific thing; but I'm not the guy who is going to implement it. I would
> recommend talking to the GLEP author (robbat2@gentoo.org)
>

Thank you.  We'll contact the GLEP author to discuss the standard.



>
> -A
>
>
>>
>>
>> --
>> vladimir.v.diaz@gmail.com
>> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
>> --
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7585 bytes --]