On Sun, 15 Mar 2015 18:27:06 -0400 Vladimir Diaz <[email protected]> wrote:
> On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <[email protected]> > wrote: > > > On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz > > <[email protected]> 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 ([email protected]) > > > > Thank you. We'll contact the GLEP author to discuss the standard. > > > robbat2 is the infra lead, so that is the correct person to contact. I've held off replying so far because I'm trying to get some time to figure out your system. I'm not sure yet whether your system will fit the plans and structure for our main tree. git now has signed commit support, which was a request gentoo had made long ago in order for our migration to git from cvs. Until recent versions it was not easy to re-verify a signed commit. We have have signed Manifest support in the system for some time now, but have not been enforcing it fully up till now. We have a new project called gentoo-keys [1] which is a gpg key management app and libs to handle the various gpg keys from devs, release media, and others. We are in the process of getting our devs to create/update their gpg keys to meet the new minimum spec (GLEP 63). I am just starting to integrate gkeys libs use into portage to verify the package Manifests which is similar to what you do. With the git migration, commits must be signed, but will be using a "thin" manifest rather than the full one. Instead we will be enforcing the --sign option for git push (recently added to git). That will use gkeys to verify the pushed content via a hook and replacement gpg command that uses gkeys. So the main git repo will be secured similar to what I've gleaned from your code so far. The main syncing of the tree for users will be done via rsync still, but for that the full Manifest files will be (re)generated as needed and signed with an infra controlled key. Normal users system will be able to verify those Manifests. There is also optional versions of the tree which are signed in total (emerge-webrsync) and verify-able. As has been pointed out the other thread [3] which was started just before this one. We are in a different place than what the binary distributions are in terms of repositories. Not all attack vectors your code is meant to address applies to our situation. I do think your repository manifest was something that robbat2 had talked about implementing for overlay maintainers as an option for layman to be able to verify updates to the overlay repos. It would likely have to be generated from a VCS hook which runs when commits are made/pushed. I'd love to hear how your code can fit in to the Gentoo system. links: [1] http://gitweb.gentoo.org/proj/gentoo-keys.git/ gkeys article in LWN: http://lwn.net/Articles/634777/ [3] http://archives.gentoo.org/gentoo-portage-dev/message/bda425ee6c676ec7a6b3c9500a9b00bf -- Brian Dolbec <dolsen>
