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
On Sat, 2015-12-19 at 09:49 -0800, Alice Wonder wrote:> DNS verification solves that issue.How reliably safe is that ? Crack the DNS access and inflict viruses, trojans etc. with authorised impunity ? Happy Christmas. -- Regards, Paul. England, EU. England's place is in the European Union.
On 12/19/2015 10:27 AM, Always Learning wrote:> > On Sat, 2015-12-19 at 09:49 -0800, Alice Wonder wrote: > >> DNS verification solves that issue. > > How reliably safe is that ? > Crack the DNS access and inflict viruses, trojans etc. with authorised > impunity ? > > Happy Christmas.No, if you manage to crack the DNS you can not do anything but a DOS attack unless you also managed the get the DNSSEC signing key, which does not need (and should not be) to be on the DNS server. Manage to get the signing key, and the only consequence is the attacker can make fraudulent DNS entries that would validate - same as with GPG or any other private / public key cryptographic signatures.
On 12/19/2015 09:49 AM, Alice Wonder wrote:> > With third party repositories the key and configuration file is often > distributed separately. That's the potential attack vector for trojan > keys.Examples? All of the notable repositories that I'm aware of publish an x-release.rpm that installs their key and yum repo file. But if your concern is that users might manually install a repo file and public key, then I don't see how modifying yum would change that. The attacker would probably include a key that contains an address they control and validates properly against it. In other words, I think the solution to the problem is simply to make sure that the repositories publish their "release" rpm over https and that documentation reflects the secure URL. I notice now that EPEL links directly to the https URL for their release rpm, but their FAQ still provides a command-line example for installation using an http URL. The FAQ should be updated. That method is a potential security problem because it doesn't use https and doesn't check the package signature. But the solution is simply to replace http with https in the FAQ. yum isn't used to install the release package, and I think the solution is to make sure that malicious release packages don't get installed, not to try to behave well on a system where an attacker already installed malicious data.
On 20/12/15 10:28, Gordon Messmer wrote:> On 12/19/2015 09:49 AM, Alice Wonder wrote: >> >> With third party repositories the key and configuration file is often >> distributed separately. That's the potential attack vector for trojan >> keys. > > Examples? > > All of the notable repositories that I'm aware of publish an > x-release.rpm that installs their key and yum repo file. But if your > concern is that users might manually install a repo file and public key, > then I don't see how modifying yum would change that. The attacker would > probably include a key that contains an address they control and > validates properly against it. > > In other words, I think the solution to the problem is simply to make > sure that the repositories publish their "release" rpm over https and > that documentation reflects the secure URL. I notice now that EPEL > links directly to the https URL for their release rpm, but their FAQ > still provides a command-line example for installation using an http URL. > > The FAQ should be updated. That method is a potential security problem > because it doesn't use https and doesn't check the package signature. > But the solution is simply to replace http with https in the FAQ. yum > isn't used to install the release package, and I think the solution is > to make sure that malicious release packages don't get installed, not to > try to behave well on a system where an attacker already installed > malicious data. >Unless I'm mistaken RPM in el5 does not support the https protocol.