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@fedoraproject.org
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(a)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(a)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/Everyt...
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(a)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(a)fedoraproject.org>"
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(a)malicious.example email. Then DNF will tell me:
Importing GPG key 0x45719A39:
Userid : "hahah <brad.guy(a)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(a)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(a)malicious.example is correct.
I would need to be dumb to allow import of brad.guy(a)malicious.example
GPG key.
Attacker learned the lesson and he created new GPG pair and he use email
address fedora-34-primary(a)fedoraproject.org. 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(a)fedoraproject.org>"
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(a)fedoraproject.org>"
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(a)domain.com 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(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB