I think Björn's point is valid note. Because DNSSEC is used to verify email of used key, but fedora.repo does not contain any hint about how email in GPG key should look like. Also does not contain fingerprint of such key. It would be nice to include email of included GPG key in repo file itself. If actual email in GPG did not match, dnf would refuse such key unless explicitly requested by user. What if we added to repos: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch gpgkeyid=mailto:fedora-$releasever-primary@xxxxxxxxxxxxxxxxx This way dnf could map DNSSEC validated email to repository. It would be user-verifiable, when he or she would add a new repository downloaded from any site. That is especially valid if user just changed --releasever, but repository file remains from trusted source. Installing unsigned package provides no way to ensure it cames from trusted source. There is anything we can do about that, admin either knows what he does or can be fooled to anything. I don't understand why old keys don't provide transition to new keys, while they are still valid. DNSSEC allows us to ensure they are still current and non-revoked. But still, when I use dnf install --releasever 35 <something>, it asks me for confirmation of new f35 key. But If I already trust f33 key, it might sign f35 key before obsoleted itself. It would provide me safe upgrade path to new release keys. Is there reason why we consider new release keys as completely unrelated to previous keys? Is it technical decision or just lack of better implementation? Regards, Petr On 3/9/21 4:56 PM, Miroslav Suchý wrote: > Dne 08. 03. 21 v 15:01 Björn Persson napsal(a): >> Suppose a bad guy has somehow tricked you into downloading a malicious >> version of rpmfusion-free-release. The package is signed by >> brad.guy@malicious.example, and the key is published in the domain >> malicious.example. All the DNSsec signatures are in perfect order, so >> you can be quite sure that the key really does belong to >> brad.guy@malicious.example. Do you trust Brad? Should you install the >> package? > > Let's compare it to a current situation. I deleted F34 and F35 GPG keys > from my system. > > When I tried to run (and I used distribution-gpg-key package for the test): > > # dnf install > http://ftp.halifax.rwth-aachen.de/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/d/distribution-gpg-keys-1.51-1.fc35.noarch.rpm > > > Then DNF does not blink an eye and install this package even when the > GPG keys is not known. (it is because of default setting of > localpkg_gpgcheck). > > BTW when I try: > # rpm -i distribution-gpg-keys-1.51-1.fc35.noarch.rpm > warning: distribution-gpg-keys-1.51-1.fc35.noarch.rpm: Header V4 > RSA/SHA256 Signature, key ID 9867c58f: NOKEY > > I.e. the package have been installed. Though rpm emits a warning. But I > doubt that average sysadmin would treat this warning seriously. > > And if you download and install package containing .repo file where > baseurl points to malicious repo and the package install malicious GPG > key, then you are screwed anyway. > In postscriptlet, or unit file, you can import the GPG key to rpmdb and > do whatever you want. > > It does not matter if you used DNS(SEC) verification or not. You simple > should check the GPG key and you should not trust the key emmited by > brad.guy@malicious.example. > > >> Obviously we want a package signed by an attacker to fail the >> verification. Section 3 of your thesis describes how the modified DNF >> uses DNSsec to verify that the key is valid for the stated email >> address, but I don't see anything about how it decides whether the >> email address is correct for the repository, or whether the person >> behind that email address is trusted. You state that the DNS server >> isn't necessarily in the same domain as the repository, so it's not as >> simple as comparing the domain names. Could you explain how the email >> address is validated? > > The domain for the repository above is ftp.halifax.rwth-aachen.de, but > the GPG key for packages there use @fedoraproject.org. That's what an > author meant. > > > Now, lets try something little different. I still do not have F34 and > F35 GPG keys. I am on F33. And lets run: > > # dnf install --releasever=34 distribution-gpg-keys > ... > Installed size: 434 k > Is this ok [y/N]: y > Downloading Packages: > ... > Importing GPG key 0x45719A39: > Userid : "Fedora (34) <fedora-34-primary@xxxxxxxxxxxxxxxxx>" > Fingerprint: 8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39 > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 > Is this ok [y/N]: > > That is interesting. Let pretend that attacker changed something by MITM > attack and tricked me to download his package. If he signed package > using brad.guy@malicious.example email. Then DNF will tell me: > > Importing GPG key 0x45719A39: > Userid : "hahah <brad.guy@malicious.example>" > Fingerprint: some thing bad and not matching > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 > > The package is signed using brad.guy@malicious.example and if he has > corresponding DNS entry and DNSSEC on malicious.example, then DNF tells me: > Verified using DNS record with DNSSEC signature. > I.e. that owner of malicious.example domain say that GPG key for > brad.guy@malicious.example is correct. > I would need to be dumb to allow import of brad.guy@malicious.example > GPG key. > > Attacker learned the lesson and he created new GPG pair and he use email > address fedora-34-primary@xxxxxxxxxxxxxxxxx. GPG will not stop you. And > it is okay to have several GPG keys for one email (CentOS does that). > > I run dnf again and DNF tells me: > Importing GPG key 0x45719A39: > Userid : "Fedora (34) <fedora-34-primary@xxxxxxxxxxxxxxxxx>" > Fingerprint: some thing not correct > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 > Is this ok [y/N]: > > The email match. The filename match. Fingerprint? That is long, there is > no time. It is ok, proceed.... and voila, I am hacked. > > Let's try that with > gpgkey_dns_verification=1 > > Importing GPG key 0x45719A39: > Userid : "Fedora (34) <fedora-34-primary@xxxxxxxxxxxxxxxxx>" > Fingerprint: some thing not correct > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 > NOT verified using DNS record. > Is this ok [y/N]: > > That sounds fishy. I will try to check the fingerprint. But even if I > proceed. Then every time DNF starts, it will check the DNS entries and I > will get: > > "GPG Key {} could not be verified, because DNSSEC signatures" > " are bogus. Possible causes: wrong configuration of the DNS" > " server, MITM attack".format(key.email) > > > This is getting long. What is the conclusion? GPG in DNS is not > equivalent of **authorization**. It is still up to admin to approve the > key. And it will not open your system. Not more than it is now. > GPG in DNS is more equivalent of **authentication**. You will not need > to compute fingerprint and manually compare it with fingerprint on > website (or what you are using). > When the email is foo@xxxxxxxxxx and have DNS(SEC) entry then you can be > sure that the domain owner confirms the identity of that GPG keys. It is > up to you whether you will trust the owner of that domain. > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
