I'm not on the yum / RPM list and I don't know that I want to join just to discuss this but with respect GPG keys - it is a classic example of trust on first use. The first time yum installs a package, it asks to import the GPG key used to sign the packages. Most people accept without validating the key. This is potentially exploitable because most repositories are http What if there was a DNS TXT record that corresponds with the repository, with the fingerprint of the key? The DNS record could be DNSSEC secured (I believe Fedora already uses DNSSEC - some of their servers anyway) and yum could refuse to ask if the fingerprint of the key it is importing does not match the DNSSEC secured fingerprint. Something like TXT record for _rpmkey.security.centos.org. could be requested for the fingerprint for security at centos.org Advantage over gpg keyrings is that it can be implemented by anyone without needing to manage your keys with specific gpg keyrings, which has always been messy. When yum is first asked to import a key, it refuses if it can not DNSSEC validate the fingerprint. After it DNSSEC validates the fingerprint, it can then does what it currently does, where the user can verify they trust the key. To get a fingerprint in the centos.org zone and signed by DNSSEC would not be easy for a malicious packager to do. Furthermore when a signing key has been compromised (happened with Fedora once) changing the DNS record would prevent the key from being imported in the future, and could even prevent packages signed by that key from being installed in the future even if the key is already imported. For offline yum usage, a switch could be used to tell yum not to do the DNS lookup and DNSSEC validation. Thoughts?
On 16/12/15 03:05, Alice Wonder wrote:> I'm not on the yum / RPM list and I don't know that I want to join just > to discuss this but with respect GPG keys - it is a classic example of > trust on first use. > > The first time yum installs a package, it asks to import the GPG key > used to sign the packages. Most people accept without validating the key. >This is a huge issue, its something we've debated many times and I dont think there is a clear answer, yet. At this point we have yum use the gpg keys setup at install time, from the install media - it should not be going over the wire to grab keys. And we sign the install media, and its sha sum's - so uses can verify things. the underlaying thinking being that if the install media is compromised, anything it does and any content it grabs over the wire should be considered potentially compromised - so enforce the idea of media test, media validation, and deliver the first ring of trust via the media. Having said that, your point about using DNS as a second way to verify the keys is a good one, I believe its come up in the past as well. And we have a todo item to get dnssec up for centos.org in the near future. what I would recommend, is to open an issue report at bugs.centos.org/ to track this as a task. As a related subject, we do push the main key fingerprints via https at www.centos.org/keys regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
On 12/15/2015 07:05 PM, Alice Wonder wrote:> The first time yum installs a package, it asks to import the GPG key > used to sign the packages. Most people accept without validating the key.While that is true, it is important to note that yum will only import keys that are already installed on disk, in /etc/pki/rpm-gpg. Which means that only keys that were *previously* installed from a trusted source can be added to the trust database. Initially, that set comes from your install media. Assuming that you verified the sum of the media you used for installation, this is a reasonably secure mechanism.> This is potentially exploitable because most repositories are httphttp repositories don't impact the security of this mechanism in any way. If you're worried about the package verification process, the big risk that exists in the current implementation (assuming that you trust your install media) is that users are allowed to install repositories that are configured with both gpgcheck=0 AND an http:// URL. That combination could lead to a compromise through a MITM attack, but only if a third-party repository is added, and that repo doesn't provide any security at all.> The DNS record could be DNSSEC secured (I believe Fedora already uses > DNSSEC - some of their servers anyway) and yum could refuse to ask if > the fingerprint of the key it is importing does not match the DNSSEC > secured fingerprint....> When yum is first asked to import a key, it refuses if it can not > DNSSEC validate the fingerprint.And what should it do at sites where there's no DNSSEC validation available? Are they unable to install packages? Should it fall back to its current behavior? I think that's an important question, because if you're trying to improve security in the face of a MITM attack, you have to be able to demonstrate that security is actually better *during an attack*. If a MITM can simply cause the client to fall back to its current behavior in order to launch a hypothetical attack, your solution isn't suitable.> Furthermore when a signing key has been compromised (happened with > Fedora once) changing the DNS record would prevent the key from being > imported in the future, and could even prevent packages signed by that > key from being installed in the future even if the key is already > imported.If you're going to verify the key against a DNS record for every package you install, forever, why have a GPG keyring at all?
On 12/19/2015 02:12 AM, Gordon Messmer wrote:> On 12/15/2015 07:05 PM, Alice Wonder wrote: >> The first time yum installs a package, it asks to import the GPG key >> used to sign the packages. Most people accept without validating the key. > > While that is true, it is important to note that yum will only import > keys that are already installed on disk, in /etc/pki/rpm-gpg. Which > means that only keys that were *previously* installed from a trusted > source can be added to the trust database. Initially, that set comes > from your install media. Assuming that you verified the sum of the > media you used for installation, this is a reasonably secure mechanism.With third party repositories the key and configuration file is often distributed separately. That's the potential attack vector for trojan keys.> > If you're going to verify the key against a DNS record for every package > you install, forever, why have a GPG keyring at all?Well I'm not a big fan of GPG keyrings to be honest, it is a difficult system for users and contains abandoned keys and compromised keys that aren't revoked because the owner can't revoke them if they lost their private key. DNS verification solves that issue. -- -=- Sent my from my laptop, may not be able to respond timely