Il giorno 29/lug/2014, alle ore 02:39, Nick Coghlan <ncogh...@gmail.com> ha scritto: > On 29 Jul 2014 10:01, "Giovanni Bajo" <ra...@develer.com> wrote: > > > > Il giorno 29/lug/2014, alle ore 01:36, Nick Coghlan <ncogh...@gmail.com> ha > > scritto: > >> > >> On 29 Jul 2014 03:43, "Giovanni Bajo" <ra...@develer.com> wrote: > >> > > >> > Hello, > >> > > >> > on March 2013, on the now-closed catalog-sig mailing-list, I submitted a > >> > proposal for fixing several security problems in PyPI, pip and > >> > distutils[1]. Some of my proposals were obvious things like downloading > >> > packages through SSL, which was already in progress of being designed > >> > and implemented. Others, like GPG package signing, were discussed for > >> > several days/weeks, but ended up in discussion paralysis because of the > >> > upcoming TUF framework. > >> > >> It stalled because end-to-end signing is a hard security problem and "just > >> add GPG!" isn't an answer. > > > > I don’t find it very fair that you collapse a 700-line document to “just > > add GPG”. And even in March, I wrote and proposed an extensive document. > > I’m not jumping into discussions handwaving a couple of buzzwords. > > If your PEP defends against all the attacks TUF does, then it will be just as > complicated as TUF. If it doesn't defend against all those attacks, then it > offers even less justification for the complexity increase than TUF. > 1) TUF isn’t designed for PyPI and pip. It’s a generic system meant for many different scenarios, which is then adapted (with many different compromises) to our use case. So you can’t really postulate that you absolutely need something as complicated to get to the same level of defense. 2) Security is never perfection. You might very well decide that the increased level of security is not worth the complexity increase.
My solution is far far simpler than TUF. To me, it’s a reasonable compromise between complexity of implementation, time/costs required for all involved parties, and decreased security. > >> If you add a threat model to the draft PEP, then we can have a useful > >> discussion, > > > > There is a whole section called "threat model”. If you would like to see > > the threat model extended to cover different attacks, I reckon there’s a > > less aggressive way to phrase your opinion. > > My apologies, it is customary to explain the threat model *before* proposing > a solution to it, and I did indeed lose patience before reaching that part of > the PEP. I have now read that section, and still find it lacking compared to > the comprehensive threat analysis research backing TUF. > If it’s only “lacking", then i’m happy, as that PEP is not my PhD dissertation :) > >> 1. People like Donald, Ernest, Richard Noah (i.e. PyPI and infrastructure > >> admins) are part of the threat model for PEP 458. How does your PEP defend > >> against full compromise of those accounts? > > > > > It doesn’t, nor PEP 458 does. If an attacker owns a root shell on PyPI, it > > is game over with both PEPs; that is, unless you’re referring to the > > claimed role for which PEP 458 is severely lacking the most important and > > hard thing: how to populate it. > > PEP 458 includes both offline root keys and an "N of M" signing model > specifically so compromise of a single administrator account can't break the > whole system (aside from DoS attacks). > It depends on your definition of “compromise of a single administrator”. Obviously if you compromise the root signing key, then yes, the N/M model helps, but that key doesn’t exist in my PEP in the first place (which means that my PEP is simpler, requires less work on administrators, less key management, etc.). If with “compromise of an administrator” you intend that an attacker can login into PyPI and become root, than I maintain that PEP458 and my PEP are mostly equivalent, in that they offer close to no protection; the attacker can compromise all packages. PEP458 then has this “claimed” role that is signed with an offline key, which would protect from a PyPI compromise, and which Donald says it’s the only reason he cares about PEP458. But it totally punts on how to maintain that role from a practical standpoint; how do you move projects into there? How do verify author keys (and identities)? How do you handle the offline verifications of keys from maintainers all over the world? Should the PSF setup a telephone line for that? Should outsource some identity verification to an external company? How do you protect from different kind of social engineering? I did some researches on the topic a couple of years ago, and it’s a very tough topic. Having the software part that can handle offline signing is the easiest part. > >> 2. What level of damage mitigation are we aiming to attain in the event of > >> a full PyPI compromise? (i.e. attacker has full control over absolutely > >> everything published from PyPI) > > > > I’m not sure I understand the question or how it differs from the previous > > one. The thread model section on "PyPI server compromise” in my PEP has > > some details though. > > And it amounts to minimal additional defence beyond where we are today. > Yes. I don’t claim otherwise either. > >> 3. Assuming an attacker has fully compromised DNS and SSL (and hence can > >> manipulate or replace *all* data purportedly being received from PyPI by a > >> given target), what additional level of integrity is the "end-to-end" > >> signing process adding? > > > > In all cases in which the trust file is cached / edited with no automatic > > updates, it fully guarantees that no compromised packages can be installed > > in the user machine. This wouldn’t be the standard setup for most users. > > Except it allows known-vulnerable versions to be installed. > Well, known-vulnerable versions are a problem in deployments, not development. If you’re fully compromising DNS and SSL of a deployment machine, there are far easier way to attack your target. Moreover, in deployments, most people do fix versions of packages they install. I don’t think anybody is running deployments in which they install whatever latest version of Django PyPI serves them. In that case, serving a different version would still make pip abort installation. Protecting development machines against code execution is fully achieved by my PEP with a manually-edited (or peep-like edited) trust file. > >> 4. What level of guarantee will be associated with the signing keys, and > >> are package authors prepared to offer those guarantees? (The only dev > >> community I've really talked to about that is a few of the Django core > >> devs, and their reaction was "Hell, no, protecting and managing keys is > >> too hard”) > > > > If package authors are unwilling to handle signing keys, PEP 458 is also > > doomed, and moreso since it would use an obscure, custom, one-purpose > > signing key and key tools, with no extensive documentation on proper > > handling on multiple operating systems and development scenarios. I thus > > don’t see how this question is pertinent in evaluating my PEP vs PEP 458. > > The signing algorithm isn't the interesting part of TUF - it's the key > management and trust delegation. This question is relevant to both proposals, > as the case where PyPI is signing on behalf of the developer is a critical > one to handle in order to keep barriers to entry low. > > A "solution" that leads to end users just turning off signature checking > (because most packages aren't signed) is undesirable, as it means missing out > on the additional integrity checks for the PyPI-user link, even if those > packages are still vulnerable to PyPI compromise. > you don’t need to turn off signature checking, you can simply allow installation of packages with missing GPG signatures. So again, if developers refuse to touch keys, you’re not affecting security of users installing signed packages. > >> 5. How do these guarantees compare to the much simpler SSH inspired "trust > >> on first use" model already offered by "peep"? > > > > I’m not very familiar with peep, but my understanding is that it doesn’t > > help at all for package upgrades; if an attacker compromises the latest > > release of Django, any user installing that release for the first time in > > each virtualenv wouldn’t realize it. > > peep is designed to be used in conjunction with version pinning - upgrades > happen deliberately rather than implicitly. > yes, but WHEN upgrades do happen, peep offers no security; instead, my proposal does offer security in that the new never-seen-before package can still be checked for authentication (through the signature). -- Giovanni Bajo :: ra...@develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
