[Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security

[Justin Cappos]

Once again, apologies for being mostly out of this discussion for the next
10 days or so, but I did want to jump in and clarify a point.

TUF can be used exactly with a one-key-per-devel model.   (If fact, see our
CCS 10 paper on this for details.)   It's possible to revoke keys and have
split keys, etc. but a "simple" developer setup is just as simple as what
you propose.

Thanks,
Justin




On Mon, Feb 11, 2013 at 2:26 PM, Giovanni Bajo <rasky at develer.com> wrote:

> Il giorno 10/feb/2013, alle ore 23:20, Jesse Noller <jnoller at gmail.com>
> ha scritto:
>
>
>
> On Feb 10, 2013, at 7:54 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On Sun, Feb 10, 2013 at 10:36 PM, Jannis Leidel <jannis at leidel.info>
> wrote:
>
>
> On 10.02.2013, at 05:44, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>
> On Sun, Feb 10, 2013 at 7:23 AM, Giovanni Bajo <rasky at develer.com> wrote:
>
> Hello,
>
>
> my proposal for fixing PyPI and pip security is here:
>
>
> https://docs.google.com/a/develer.com/document/d/1DgQdDCZY5LiTY5mvfxVVE4MTWiaqIGccK3QCUI8np4k/edit#
>
>
> I tried to sum up the discussions we had here last week, elaborating on
> Heimes' proposal by simplifying it where I thought the additional steps
> wouldn't guarantee additional security. At this point, the proposal does
> not include a central, uber-master online GPG signing key to be stored on
> PyPI, which is IMO quite hard to handle correctly.
>
>
> I think the parts related to improving the HTTPS/SSL based security
>
> are solid, but for the other aspects of secure updates, integrating
>
> TUF (https://www.updateframework.com/) into the PyPI based
>
> distribution infrastructure sounds like the best available option for
>
> enhancing the end-to-end integrity checking. TUF has a comparatively
>
> well-developed threat model, and systematically covers many of the
>
> attack vectors discussed in the past few day (including provision of
>
> old, known vulnerable, versions).
>
>
> Would you mind explaining why TUF is good?
>
>
> The main benefit in my mind is that it isn't a from-scratch design of
> a secure update infrastructure. Instead, it's a project that was
> started in order to resolve some security holes found in Tor's already
> robust automatic update mechanism, then proceeded from there into
> updates to yum, yast, apt, etc (i.e. the distro update mechanisms that
> are vetted by the security teams of the various Linux vendors). The
> fact Geremy Condra is involved in TUF also counts for a lot with me
> (as I suspect it would for many people that have heard Geremy talk
> about security issues in Python).
>
> However, the design itself also seems sensible, and is able to provide
> its security guarantees even if you're *not* using SSL certs to
> protect the in-flight traffic (thus meaning that the SSL
> infrastructure in the near term will become a matter of providing
> defence-in-depth, rather than being a required part of the security
> scheme).
>
> I trust our collective ability to make TUF sufficiently easy to use as
> part of Python's packaging infrastructure a *lot* more than I trust
> our collective ability to come up with a from-scratch distribution
> scheme that is both usable *and* secure.
>
> The site doesn't seem to work for me right now.
>
>
> D'oh, looks like their domain wasn't set to auto-renew :(
>
> Cheers,
> Nick.
>
>
> Feedback from Geremy below:
>
> OK, so, I think there's a lot of stuff conflated here. It'll probably help
> to simplify things if we decouple them.
>
> First, the point about serving metadata over a secure channel and data
> over a cheap one is right on. Given the size of your metadata versus actual
> data, maintaining a central metadata service but not caring about where/how
> data is hosted is the right way to go. Note that that channel doesn't have
> to be SSL- a verifying cert on device would still give you everything you
> needed.
>
> Second, decouple the transport-level problem from verifying code. SSL is
> good, but it doesn't provide end to end security, which is what you care
> about here. A good alternative is the Android model, with per developer
> keys- it keeps attribution with code and clients can verify that the key is
> correct based on the current and possibly previous signed metadata bundle.
>
> The Android model is the self-signed model (aka SSH model), where an user
> is presented with a self-signed certificate and just needs to press Yes
> without verifying. In fact, Android doesn't even ask the question to the
> user, and it assumes that everything you download from the app store is
> "correct". So in a way, the main protection it offers is that it's not
> possible for another user to publish an application with the same name on
> the Android market, but AFAIK if I download an application, insert a
> malware, sign it myself, and directly send to a victim, the victim will
> have no way to realize the application has a wrong signature (unless it's
> been installed before).
>
> The Android model works well for their use cases, but we can do more than
> that. In our case, users install packages with their unique package name,
> so we are able to make sure pip will refuse to install a package named
> "django", even if it comes from a different source, because it will always
> be able to double check with PyPI.
>
> Plus, our advanced users might want to have a fixed trust list, never
> updated from PyPI, which is allowed in my design.
>
> It's also very understandable for developers, who we found sometimes got
> confused by TUFs many keys, integrates well with managed hsm solutions like
> verisign's, and can integrate with scm's for really nice commit-level
> authentication.
>
> To clarify, the above statements also apply to the design I propose (which
> is actually the one that is already present, with --sign). It doesn't apply
> to TUF.
>
> It's interesting that Geremy says that the TUF model is confusing -- I
> have never used it, but it in fact looked a little too complicated for our
> average package maintainer. If we were worried about making them create a
> single GPG key with a single command line, here we're talking of handling 4
> different keys (maybe 3 if timestamping key is handled by PyPI).
>
> The major attack left in this model is a compromise of the metadata server
> key, which is the problem TUF was designed to address. In practice, you are
> going to have a bad time if this happens, since TUF converts this
> compromise into a denial of service some period of time later. I'll have to
> think a bit about whether this is good enough for you, but I'm inclined to
> say no based on the difficulty of doing audits on so much output. Might
> just be best to simplify the system and keep this aspect hardened and
> trusted. Happy to talk more about that if you're interested.
>
> Sure, can he join the discussion? I'm also available for a chat, or a call.
>
>  --
> Giovanni Bajo   ::  rasky at develer.com
> Develer S.r.l.  ::  http://www.develer.com
>
> My Blog: http://giovanni.bajo.it
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130211/4f983dd2/attachment.html>