Switch dom0 RPM to use the kernel crypto API

[DemiMarie]

Qubes OS version (if applicable)

Qubes release 4.0 (R4.0)

Affected component(s) or functionality (if applicable)

dom0 RPM

Brief summary

dom0 uses reasonably up-to-date kernels but an extremely outdated userland. Therefore, it is desirable for update signature verification to be done in kernel mode using the kernel crypto API.

Additional context

From a security perspective, RPM and rpmcanon run with kernel-equivalent privilege anyway. And the kernel crypto code is presumably maintained, whereas our ancient OpenSSL or NSS is not. Also, the kernel crypto API (exposed via AF_ALG) is likely to have been fuzzed and otherwise hardened against malicious inputs, since it is accessible to unprivileged users. That makes me worry a bit less about designs in which an attacker can submit a series of buffers of attacker-controlled lengths to a hash function.

Relevant documentation you've consulted

Related, non-duplicate issues

[HW42]

Using something maintained for the crypto in rpm is a great idea. But I don't think that switching to the kernel crypto API is a good fit:

• AFAIK the kernel crypto mainly targets things relevant for the in-kernel usage (like dm-crypt). For example when we discussed dm-integrity recently some common AEAD schemes weren't available (like XChaCha20-Poly1305).
• The kernel crypto API has a reputation for being quite complex. IIRC that was the main factor for wireguard not using it (and yes wireguard is part of the kernel so not quite the same as some user space program).
  • In addition in this use case things are complicated by this (in my experience) unusual dependency between kernel and rpm. So for example users updating kernels now have to be careful that it includes the right crypto modules.
• Changing rpm to use it requires effort. Just updating the existing lib (OpenSSL IIUC) seems like the easier way forward.
• In general I think moving crypto to the kernel is an odd design unless you deal with hardware accelerators (the system rng is special, that's indeed a job for the kernel). What do we win for the added complexity compared to use a user space lib?
• This derivatives from upstream and given the rest I don't think that's worth it.

What I would do instead (can be done independently from each other):

• Update the OpenSSL used by rpm
• Verify the signature in rpmcanon already (using something hopefully safer like https://sequoia-pgp.org/)
  • In addition to the existing validation in rpmcanon this would in general reduce the exposure of rpm (not only the crypto part) further, since only packages with a valid signature from a trusted key would get passed to rpm at all.

[DemiMarie]

Using something maintained for the crypto in rpm is a great idea. But I don't think that switching to the kernel crypto API is a good fit:

• AFAIK the kernel crypto mainly targets things relevant for the in-kernel usage (like dm-crypt). For example when we discussed dm-integrity recently some common AEAD schemes weren't available (like XChaCha20-Poly1305).

Indeed. Though it does need signature algorithms for Secure Boot stuff and kernel module signing.

• The kernel crypto API has a reputation for being quite complex. IIRC that was the main factor for wireguard not using it (and yes wireguard is part of the kernel so not quite the same as some user space program).

That it does. There is a library (libkcapi) that wraps it but we could also use it ourselves.

• In addition in this use case things are complicated by this (in my experience) unusual dependency between kernel and rpm. So for example users updating kernels now have to be careful that it includes the right crypto modules.

This is for dom0, where we can just use an RPM dependency, since RPM is itself an RPM package.

• Changing rpm to use it requires effort. Just updating the existing lib (OpenSSL IIUC) seems like the easier way forward.

• In general I think moving crypto to the kernel is an odd design unless you deal with hardware accelerators (the system rng is special, that's indeed a job for the kernel). What do we win for the added complexity compared to use a user space lib?

For now, one less component we need to update ourselves. In the future, when dom0 becomes an embedded system, we could ditch OpenSSL/GnuTLS/etc entirely.

• This derivatives from upstream and given the rest I don't think that's worth it.

What I would do instead (can be done independently from each other):

• Update the OpenSSL used by rpm
• Verify the signature in rpmcanon already (using something hopefully safer like https://sequoia-pgp.org/)

The reason that rpmcanon is written the way it is is due to limitations of the librpm API. I could not figure out how to extract the RPM keyring so that I could do the cryptography myself. It turns out that rpm -qi gpg-pubkey can do that, but I was not aware of that at the time.

• In addition to the existing validation in rpmcanon this would in general reduce the exposure of rpm (not only the crypto part) further, since only packages with a valid signature from a trusted key would get passed to rpm at all.

That is already the case for everything except the OpenPGP parser, which should only receive data that has already been syntactically validated.

[marmarek]

This is for dom0, where we can just use an RPM dependency, since RPM is itself an RPM package.

But you can't make a dependency on what kernel you are running.

[DemiMarie]

This is for dom0, where we can just use an RPM dependency, since RPM is itself an RPM package.

But you can't make a dependency on what kernel you are running.

Ah, good point. But that is only an issue if the oldest kernel we ship does not have the features we need.

[hko-s]

Support for Sequoia as a backend in rpm is coming: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WCIIV7HGXW5Y7QCPKW6D3TILPOBFTCSS/