search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
527 stars 46 forks source link

Release signing keys in dom0 not signed by QMSK #9044

Open Narvey opened 4 months ago

Narvey commented 4 months ago

Qubes 4.2

Brief summary

Release keys in /etc/pki/rpm-gpg/ are not signed by the Qubes Master Signing Key

Steps to reproduce

(where vault is the name of your split-GPG qube that contains private keys, or any qube where you wish to even check signatures)

  1. in dom0: qvm-copy-to-vm vault /etc/pki/rpm-gpg/RPM-GPG-K*
  2. in valut: gpg2 --import /usr/share/qubes/qubes-master-key.asc (and trust it)
  3. in vault: gpg2 --import ~/QubesIncoming/dom0/RPM-GPG-KEY-qubes-4.2-primary (I also tried RPM-GPG-KEY-fedora-37-primary)
  4. in valut: gpg2 --check-signatures

Expected behavior

sig!3 ...blah blah sig! ... "Qubes Master Signing Key"... blah blah with correct identifier and no warnings about not knowing this key

Actual behavior

sig!3 ...blah blah (both the keys I tested were self-signed only)

Proposed solution

Put the key you get when running gpg --keyserver-options no-self-sigs-only,no-import-clean --fetch-keys https://keys.qubes-os.org/keys/qubes-release-4.2-signing-key.asc into the dom0 /etc/pki/rpm-gpg folder instead.

Narvey commented 4 months ago

see also https://forum.qubes-os.org/t/rsk-4-2-not-signed-properly/25065/7

unman commented 4 months ago

The key provided in templates is signed by the MSK. The key you import from the key-server is signed by the MSK - or at least it isnt only self-signed, because that is what you asked for. If you omit that keyserver option then you get the self-signed only key.

Can you explain why you have this expectation for the dom0 key and what security issue is.

andrewdavidwong commented 4 months ago

The key provided in templates is signed by the MSK. The key you import from the key-server is signed by the MSK

He is not referring to either of those but rather to the 4.2 RSK (and apparently certain other keys) in dom0.

Can you explain why you have this expectation for the dom0 key and what security issue is.

The expectation is that you can follow the instructions on the verifying signatures page, and they will work. That is currently not the case when you try to use the 4.2 RSK in dom0, which the instructions currently claim you should be able to do.

It's not a security issue in the sense that it creates a security vulnerability. Rather, it is a problem in that we tell users "You can do either X, Y, or Z," but X doesn't work; only Y and Z work. Another way to "solve" this problem would be to remove "X" from the documentation, but that seems like the wrong solution, since it seems like a clear oversight that different copies of the same key have different certifications. It seems highly likely that someone intended to update the key (by adding the QMSK certification) but forgot to update copies in all locations, instead updating only some of them.

Narvey commented 4 months ago

thank you @andrewdavidwong for adding clarity. Relating to your last sentence, another possible cause is that the key in dom0 came from downloading (via wget or something other than gpg with no-self-sigs-only) directly from the URL https://keys.qubes-os.org/keys/qubes-release-4.2-signing-key.asc

unman commented 4 months ago

He is not referring to either of those but rather to the 4.2 RSK (and apparently certain other keys) in dom0. I understand this. I'm just pointing out that the templates ALREADY contain signed copies of the 4.2RSK - I was not clear what the need for copying from dom0 was. You've now made that clear: there's no real need, but it's included in the documentation as a possible source.

andrewdavidwong commented 4 months ago

I'm just pointing out that the templates ALREADY contain signed copies of the 4.2RSK - I was not clear what the need for copying from dom0 was. You've now made that clear: there's no real need, but it's included in the documentation as a possible source.

Yes, but come to think of it, even if the documentation never mentioned the dom0 key, I'd argue that it's still a problem for the same RSK to be present in multiple locations and for one of the copies to be missing the QMSK certification while the others have it. That's inconsistent. If it's supposed to be the same key, then all the official copies should be the same.

A separate but related question is: What's the point of having the same RSK in both dom0 and domUs? I don't know. Ask the person who decided to do that. Maybe it's not necessary, in which case we can save ourselves some trouble by not maintaining superfluous copies of the same key in so many different locations. That would decrease the likelihood of them becoming desynchronized from each other, as happened here.

unman commented 4 months ago

Yes, but come to think of it, even if the documentation never mentioned the dom0 key, I'd argue that it's still a problem for the same RSK to be present in multiple locations and for one of the copies to be missing the QMSK certification while the others have it. That's inconsistent. If it's supposed to be the same key, then all the official copies should be the same.

I dont think this is a problem - it's fairly common under PGP to have copies of the same key signed by assorted folk. What you get from Alice may not be signed in the same way as what Bob give you - but it's the same key and can be proved to be so.

The question is, why include the "copy from dom0" option at all, when the key is available from other sources with the Qubes install? (This is different form your "Why have the key in dom0" question.) We shouldn't be promoting unnecessary use of dom0.

andrewdavidwong commented 4 months ago

I dont think this is a problem - it's fairly common under PGP to have copies of the same key signed by assorted folk. What you get from Alice may not be signed in the same way as what Bob give you - but it's the same key and can be proved to be so.

But that's a different situation. In that situation, I'm getting Alice's copy of some key, then I'm getting Bob's copy of that same key. It's understandable that those two copies might have different signatures on them, since the two copies come from two different people. In this case, however, I'm getting the same key from the Qubes OS Project in all cases. Moreover, when it comes to the key being in dom0 vs. domUs, I'm getting the same key in different locations within the same operating system (Qubes OS). It's reasonable to expect that the copies would be the same. There's no good reason for them not to be the same, and it seems like the only reason they're different is due to an oversight.

The question is, why include the "copy from dom0" option at all, when the key is available from other sources with the Qubes install? (This is different form your "Why have the key in dom0" question.) We shouldn't be promoting unnecessary use of dom0.

I suppose it could be useful in niche situations, like if I have no domUs (expert install option), or if I no longer trust any domUs (but I still trust dom0) due to some kind of suspected compromise. However, since these are niche situations, I think you should feel free to remove that part from the installation guide if you feel that such a change would be an improvement.

Narvey commented 4 months ago

I was under the impression (correct me if I'm wrong) that, while the QMSK is available in domU, the RSK(s) are only available in dom0.

andrewdavidwong commented 3 months ago

I was under the impression (correct me if I'm wrong) that, while the QMSK is available in domU, the RSK(s) are only available in dom0.

Good point. I had granted @unman's implicit assumption that the RSK(s) are also in domUs when he wrote, "The key provided in templates is signed by the MSK." However, now that I actually go to check, I don't see any RSKs in domUs. It's possible that I just don't know where to look, but the documentation doesn't seem to mention any RSKs in domUs either. @unman, can you shed some light on this?

unman commented 3 months ago

/etc/pki/rpm-gpg in Fedora templates, and thus Fedora based qubes.

andrewdavidwong commented 3 months ago

/etc/pki/rpm-gpg in Fedora templates, and thus Fedora based qubes.

Interesting. This directory doesn't seem to exist in Debian minimal qubes.

unman commented 3 months ago

Interesting. This directory doesn't seem to exist in Debian minimal qubes.

The directory isnt there to provide RSK keys. It's there to contain keys that may be used to verify Fedora packages. That's why it's missing from Debian qubes and why I specifically referred to Fedora templates and qubes. Debian templates contain the Qubes signing keys for Debian.

andrewdavidwong commented 3 months ago

The directory isnt there to provide RSK keys. It's there to contain keys that may be used to verify Fedora packages. That's why it's missing from Debian qubes and why I specifically referred to Fedora templates and qubes. Debian templates contain the Qubes signing keys for Debian.

I'm not quite sure how to interpret this, so I'll provide one possible interpretation, and you can correct it, if necessary:

The directory /etc/pki/rpm-gpg in Fedora templates is meant for holding keys related to Fedora packages. It isn't meant to hold RSKs, but it does anyway. Meanwhile, there exists an analogous directory at an unspecified location somewhere in Debian templates that is meant for holding keys related to Debian packages. This latter directory contains "the Qubes signing keys for Debian." Since RSKs are not Qubes signing keys for Debian, Debian templates do not contain RSKs. Thus, there is an inconsistency: Fedora templates contain RSKs, while Debian templates do not.