Closed andrewkrug closed 7 years ago
It looks like there's a ton of weird stuff going on in the python-gnupg project. For one there seem to be two main stream versions:
For the current release against GPG 2.3.0 on Ubuntu 14.04 against a python 3.4 virtualenv the scan_keys() function seems to not be present on the GPG object that's returned.
>>> import gnupg
>>> import os
>>> gpg_home = os.path.expanduser('~/.gnupg')
>>> gpg = gnupg.GPG(homedir=gpg_home)
I went ahead and pulled down the last 4 major releases of the module from pypy and grepped them for the method and could not find it in the GPG.py file itself so I wonder where it has been coming from. Any thoughts on this or clear requirements as guidance for freezing versions of these things @joelferrier ?
Thinking on this a little further it looks like we could just load the blob directly from the request library's output and then process that to check the fingerprint. In digging further into this it looks like this may not be working in GPG 2 and higher due to the deprecation of a dry run option that formerly output the fingerprint.
Looked into this a bit more this morning. There are plenty of OpenPGP native python libraries that can be used for native validation but none of them support integration with the systems GPG home.
So here is what I would propose:
Overall I think that this is sufficient for ensuring that there is no tampering in transit from S3 to the examiner/acquiring workstation since the process does not have end-to-end integrity. In terms of the threat model this assumes that the module can not be tampered with at the memory source ( compromised instance ). We also assume the following:
Threats at the Endpoint The greatest threat is from an attacker that completely owns the box.
@joelferrier @jparr @amccormack what do you think of this as a strategy? This is a fair amount of code to lift out and change to another PGP library and I want to make sure we're doing it right before fork-lifting libs.
+1 for a public key server - the new security boundary for finger prints and package storage +1 for using standard crypto libraries +10 for simplification
I agree. If we can't trust amazon services then why are we even doing this?
@andrewkrug @jparr sorry for my slow responses, still working on settling in after my move.
Andrew, backing up to the original message, can you clarify what you mean by when you say that GPG 2.3 has a new home directory? Does GPG 2.3 no longer use ~/.gnupg
?
I check my local virtualenv and version 0.3.9
of the python-gnupg
library has been what I've been using since at least December, is it possible the errors you have encountered were introduced in version 0.4.0
released in january?
I have no problem switching away from python-gnupg to another GPG library but will need do some research to find the best fit.
I'll try and address my thoughts on the rest of what has been covered.
scan_keys
gpg method, we should try and remove the temp file requirement when switching to a new GPG library but I don't think it should be a hard requirement for a new library.I agree with you that kernel modules are being installed in a hostile environment, and I think it is a safe assumption to assume the integrity and confidentiality of communications with Amazon and the authentication and access control functionality of KMS.
I agree with you that kernel modules are being installed in a hostile environment, and I think it is a safe assumption to assume the integrity and confidentiality of communications with Amazon and the authentication and access control functionality of KMS.
What are the potential attack vectors that signing protects us against in this case if we can not do endpoint validation?
So another thought after chatting a bit about this with Gene ( who also uses python-gnupg ).
Moments of clarity we had during the discussion:
Recommendation:
Implementation Details:
I went ahead and implemented the first part of this ( which is not any worse from a security perspective than deriving the fingerprint as we do now from the public key ) Merging PR #19 would allow this to go forward and keeps this working in Ubuntu 14.04 and other distros using GPG 2.3 or higher as native. +r on #19 @joelferrier @jparr
Thanks. This would unblock testing in the aws_ir development branch for full integrations with signing enabled.
re-opening for further discussion about fingerprint pinning
@joelferrier let's close this one out and open another issue for any further discussion on "enhancements" to the process.
GPG home directory location is different in newer versions of GPG. The repository class should detect the version and act appropriately.