Re: [gentoo-portage-dev] Portage and Update Security
Hi Brian, FYI: The OCaml and Haskell folks are working on a proposal that might be of interest to the Portage team. Thanks, Vlad P.S. Robin and I exchanged a few emails, but there doesn't seem to be much interest from his side. -- vladimir.v.d...@gmail.com PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 -- On Sun, Mar 15, 2015 at 9:23 PM, Brian Dolbec dol...@gentoo.org wrote: On Sun, 15 Mar 2015 18:27:06 -0400 Vladimir Diaz vladimir.v.d...@gmail.com wrote: On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner anta...@gentoo.org wrote: On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz vladimir.v.d...@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/247445goes 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 (robb...@gentoo.org) Thank you. We'll contact the GLEP author to discuss the standard. robbat2 is the infra lead, so
Re: [gentoo-portage-dev] Portage and Update Security
On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner anta...@gentoo.org wrote: On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz vladimir.v.d...@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/247445goes 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 (robb...@gentoo.org) Thank you. We'll contact the GLEP author to discuss the standard. -A -- vladimir.v.d...@gmail.com PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 --
Re: [gentoo-portage-dev] Portage and Update Security
On Sun, 15 Mar 2015 18:27:06 -0400 Vladimir Diaz vladimir.v.d...@gmail.com wrote: On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner anta...@gentoo.org wrote: On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz vladimir.v.d...@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/247445goes 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 (robb...@gentoo.org) 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
Re: [gentoo-portage-dev] Portage and Update Security
On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz vladimir.v.d...@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? 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. 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 (robb...@gentoo.org) -A -- vladimir.v.d...@gmail.com PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 --
