mbox series

[v2,00/14] KEYS: Add support for PGP keys and signatures

Message ID 20240818165756.629203-1-roberto.sassu@huaweicloud.com (mailing list archive)
Headers show
Series KEYS: Add support for PGP keys and signatures | expand

Message

Roberto Sassu Aug. 18, 2024, 4:57 p.m. UTC
From: Roberto Sassu <roberto.sassu@huawei.com>

Support for PGP keys and signatures was proposed by David long time ago,
before the decision of using PKCS#7 for kernel modules signatures
verification was made. After that, there has been not enough interest to
support PGP too.

Lately, when discussing a proposal of introducing fsverity signatures in
Fedora [1], developers expressed their preference on not having a separate
key for signing, which would complicate the management of the distribution.
They would be more in favor of using the same PGP key, currently used for
signing RPM headers, also for file-based signatures (not only fsverity, but
also IMA ones).

Another envisioned use case would be to add the ability to appraise RPM
headers with their existing PGP signature, so that they can be used as an
authenticated source of reference values for appraising remaining
files [2].

To make these use cases possible, introduce support for PGP keys and
signatures in the kernel, and load provided PGP keys in the built-in
keyring, so that PGP signatures of RPM headers, fsverity digests, and IMA
digests can be verified from this trust anchor.

In addition to the original version of the patch set, also introduce
support for signature verification of PGP keys, so that those keys can be
added to keyrings with a signature-based restriction (e.g. .ima). PGP keys
are searched with partial IDs, provided with signature subtype 16 (Issuer).
Search with full IDs could be supported with
draft-ietf-openpgp-rfc4880bis-10, by retrieving the information from
signature subtype 33 (Issuer Fingerprint). Due to the possibility of ID
collisions, the key_or_keyring restriction is not supported.

The patch set includes two preliminary patches: patch 1 introduces
mpi_key_length(), to get the number of bits and bytes of an MPI; patch 2
introduces rsa_parse_priv_key_raw() and rsa_parse_pub_key_raw(), to parse
an RSA key in RAW format if the ASN.1 parser returns an error.

Patches 3-5 introduce the library necessary to parse PGP keys and
signatures, whose support is added with patches 6-10. Patch 11 introduces
verify_pgp_signature() to be used by kernel subsystems (e.g. fsverity and
IMA). Patch 12 is for testing of PGP signatures. Finally, patches 13-14
allow loading a set of PGP keys from a supplied blob at boot time.

Changelog

v1 [4]:
- Remove quiet_cmd_extract_certs (redundant, likely leftover from
  conflict resolution)
- Load PGP keys embedded in the kernel image within load_module_cert()
  and load_system_certificate_list(), instead of using a separate initcall
- Style bug fixes found by checkpatch.pl
- Add <crypto/pgp.h> include in crypto/asymmetric_keys/pgp_preload.c, to
  remove no previous prototype warning
- Correctly check returned tfm in pgp_generate_fingerprint()
- Fix printing message in pgp_generate_fingerprint()
- Don't create a public key if the key blob does not contain a PGP key
  packet
- Remove unused pgp_pubkey_hash array
- Set KEY_EFLAG_DIGITALSIG key flag if the key has the capability
- Allow PGP_SIG_GENERAL_CERT_OF_UID_PUBKEY signature type (for key sigs)
- Add is_key_sig parameter to pgp_sig_get_sig() to ensure the key
  signature type is PGP_SIG_GENERAL_CERT_OF_UID_PUBKEY or
  PGP_SIG_POSTITIVE_CERT_OF_UID_PUBKEY

v0 [3]:
- style fixes
- move include/linux/pgp.h and pgplib.h to crypto/asymmetric_keys
- introduce verify_pgp_signature()
- replace KEY_ALLOC_TRUSTED flag with KEY_ALLOC_BUILT_IN
- don't fetch PGP subkeys
- drop support for DSA
- store number of MPIs in pgp_key_algo_p_num_mpi array
- replace dynamic memory allocations with static ones in
  pgp_generate_fingerprint()
- store only keys with capability of verifying signatures
- remember selection of PGP signature packet and don't repeat parsing
- move search of the PGP key to verify the signature from the beginning
  to the end of the verification process (to be similar with PKCS#7)
- don't retry key search in the session keyring from the signature
  verification code, let the caller pass the desired keyring
- for the PGP signature test key type, retry the key search in the session
  keyring
- retry key search in restrict_link_by_signature() with a partial ID
  (provided in the PGP signature)

[1] https://fedoraproject.org/wiki/Changes/FsVerityRPM
[2] https://lore.kernel.org/linux-integrity/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git/log/?h=pgp-parser
[4] https://lore.kernel.org/linux-integrity/20220111180318.591029-1-roberto.sassu@huawei.com/

David Howells (8):
  PGPLIB: PGP definitions (RFC 4880)
  PGPLIB: Basic packet parser
  PGPLIB: Signature parser
  KEYS: PGP data parser
  KEYS: Provide PGP key description autogeneration
  KEYS: PGP-based public key signature verification
  PGP: Provide a key type for testing PGP signatures
  KEYS: Provide a function to load keys from a PGP keyring blob

Roberto Sassu (6):
  mpi: Introduce mpi_key_length()
  rsa: add parser of raw format
  KEYS: Retry asym key search with partial ID in
    restrict_link_by_signature()
  KEYS: Calculate key digest and get signature of the key
  verification: introduce verify_pgp_signature()
  KEYS: Introduce load_pgp_public_keyring()

 MAINTAINERS                             |   1 +
 certs/Kconfig                           |  11 +
 certs/Makefile                          |   7 +
 certs/system_certificates.S             |  18 +
 certs/system_keyring.c                  |  93 ++++
 crypto/asymmetric_keys/Kconfig          |  38 ++
 crypto/asymmetric_keys/Makefile         |  13 +
 crypto/asymmetric_keys/pgp.h            | 206 ++++++++
 crypto/asymmetric_keys/pgp_library.c    | 620 ++++++++++++++++++++++++
 crypto/asymmetric_keys/pgp_parser.h     |  18 +
 crypto/asymmetric_keys/pgp_preload.c    | 111 +++++
 crypto/asymmetric_keys/pgp_public_key.c | 492 +++++++++++++++++++
 crypto/asymmetric_keys/pgp_signature.c  | 505 +++++++++++++++++++
 crypto/asymmetric_keys/pgp_test_key.c   | 129 +++++
 crypto/asymmetric_keys/pgplib.h         |  74 +++
 crypto/asymmetric_keys/restrict.c       |  10 +-
 crypto/rsa.c                            |  14 +-
 crypto/rsa_helper.c                     |  69 +++
 include/crypto/internal/rsa.h           |   6 +
 include/crypto/pgp.h                    |  36 ++
 include/linux/mpi.h                     |   2 +
 include/linux/verification.h            |  23 +
 lib/crypto/mpi/mpicoder.c               |  33 +-
 23 files changed, 2516 insertions(+), 13 deletions(-)
 create mode 100644 crypto/asymmetric_keys/pgp.h
 create mode 100644 crypto/asymmetric_keys/pgp_library.c
 create mode 100644 crypto/asymmetric_keys/pgp_parser.h
 create mode 100644 crypto/asymmetric_keys/pgp_preload.c
 create mode 100644 crypto/asymmetric_keys/pgp_public_key.c
 create mode 100644 crypto/asymmetric_keys/pgp_signature.c
 create mode 100644 crypto/asymmetric_keys/pgp_test_key.c
 create mode 100644 crypto/asymmetric_keys/pgplib.h
 create mode 100644 include/crypto/pgp.h

Comments

Jonathan McDowell Aug. 19, 2024, 3:08 p.m. UTC | #1
On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
> 
> Support for PGP keys and signatures was proposed by David long time ago,
> before the decision of using PKCS#7 for kernel modules signatures
> verification was made. After that, there has been not enough interest to
> support PGP too.

You might want to update the RFC/bis references to RFC9580, which was
published last month and updates things.

Also, I see support for v2 + v3 keys, and this doesn't seem like a good
idea. There are cryptographic issues with fingerprints etc there and I
can't think of a good reason you'd want the kernel to support them. The
same could probably be said of DSA key support too.

> Lately, when discussing a proposal of introducing fsverity signatures in
> Fedora [1], developers expressed their preference on not having a separate
> key for signing, which would complicate the management of the distribution.
> They would be more in favor of using the same PGP key, currently used for
> signing RPM headers, also for file-based signatures (not only fsverity, but
> also IMA ones).
> 
> Another envisioned use case would be to add the ability to appraise RPM
> headers with their existing PGP signature, so that they can be used as an
> authenticated source of reference values for appraising remaining
> files [2].
> 
> To make these use cases possible, introduce support for PGP keys and
> signatures in the kernel, and load provided PGP keys in the built-in
> keyring, so that PGP signatures of RPM headers, fsverity digests, and IMA
> digests can be verified from this trust anchor.
> 
> In addition to the original version of the patch set, also introduce
> support for signature verification of PGP keys, so that those keys can be
> added to keyrings with a signature-based restriction (e.g. .ima). PGP keys
> are searched with partial IDs, provided with signature subtype 16 (Issuer).
> Search with full IDs could be supported with
> draft-ietf-openpgp-rfc4880bis-10, by retrieving the information from
> signature subtype 33 (Issuer Fingerprint). Due to the possibility of ID
> collisions, the key_or_keyring restriction is not supported.


J.
Roberto Sassu Aug. 19, 2024, 3:15 p.m. UTC | #2
On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> > 
> > Support for PGP keys and signatures was proposed by David long time ago,
> > before the decision of using PKCS#7 for kernel modules signatures
> > verification was made. After that, there has been not enough interest to
> > support PGP too.
> 
> You might want to update the RFC/bis references to RFC9580, which was
> published last month and updates things.

Yes, makes sense (but probably isn't too much hassle to support more
things for our purposes?)

> Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> idea. There are cryptographic issues with fingerprints etc there and I
> can't think of a good reason you'd want the kernel to support them. The
> same could probably be said of DSA key support too.

Uhm, if I remember correctly I encountered some old PGP keys used to
verify RPM packages (need to check). DSA keys are not supported, since
the algorithm is not in the kernel.

Thanks

Roberto

> > Lately, when discussing a proposal of introducing fsverity signatures in
> > Fedora [1], developers expressed their preference on not having a separate
> > key for signing, which would complicate the management of the distribution.
> > They would be more in favor of using the same PGP key, currently used for
> > signing RPM headers, also for file-based signatures (not only fsverity, but
> > also IMA ones).
> > 
> > Another envisioned use case would be to add the ability to appraise RPM
> > headers with their existing PGP signature, so that they can be used as an
> > authenticated source of reference values for appraising remaining
> > files [2].
> > 
> > To make these use cases possible, introduce support for PGP keys and
> > signatures in the kernel, and load provided PGP keys in the built-in
> > keyring, so that PGP signatures of RPM headers, fsverity digests, and IMA
> > digests can be verified from this trust anchor.
> > 
> > In addition to the original version of the patch set, also introduce
> > support for signature verification of PGP keys, so that those keys can be
> > added to keyrings with a signature-based restriction (e.g. .ima). PGP keys
> > are searched with partial IDs, provided with signature subtype 16 (Issuer).
> > Search with full IDs could be supported with
> > draft-ietf-openpgp-rfc4880bis-10, by retrieving the information from
> > signature subtype 33 (Issuer Fingerprint). Due to the possibility of ID
> > collisions, the key_or_keyring restriction is not supported.
> 
> 
> J.
>
Roberto Sassu Aug. 19, 2024, 4:30 p.m. UTC | #3
On Sun, 2024-08-18 at 18:57 +0200, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
> 
> Support for PGP keys and signatures was proposed by David long time ago,
> before the decision of using PKCS#7 for kernel modules signatures
> verification was made. After that, there has been not enough interest to
> support PGP too.
> 
> Lately, when discussing a proposal of introducing fsverity signatures in
> Fedora [1], developers expressed their preference on not having a separate
> key for signing, which would complicate the management of the distribution.
> They would be more in favor of using the same PGP key, currently used for
> signing RPM headers, also for file-based signatures (not only fsverity, but
> also IMA ones).

Update: since Fedora 39, IMA file signatures are supported on an
independent key infrastructure.

Roberto

> Another envisioned use case would be to add the ability to appraise RPM
> headers with their existing PGP signature, so that they can be used as an
> authenticated source of reference values for appraising remaining
> files [2].
> 
> To make these use cases possible, introduce support for PGP keys and
> signatures in the kernel, and load provided PGP keys in the built-in
> keyring, so that PGP signatures of RPM headers, fsverity digests, and IMA
> digests can be verified from this trust anchor.
> 
> In addition to the original version of the patch set, also introduce
> support for signature verification of PGP keys, so that those keys can be
> added to keyrings with a signature-based restriction (e.g. .ima). PGP keys
> are searched with partial IDs, provided with signature subtype 16 (Issuer).
> Search with full IDs could be supported with
> draft-ietf-openpgp-rfc4880bis-10, by retrieving the information from
> signature subtype 33 (Issuer Fingerprint). Due to the possibility of ID
> collisions, the key_or_keyring restriction is not supported.
> 
> The patch set includes two preliminary patches: patch 1 introduces
> mpi_key_length(), to get the number of bits and bytes of an MPI; patch 2
> introduces rsa_parse_priv_key_raw() and rsa_parse_pub_key_raw(), to parse
> an RSA key in RAW format if the ASN.1 parser returns an error.
> 
> Patches 3-5 introduce the library necessary to parse PGP keys and
> signatures, whose support is added with patches 6-10. Patch 11 introduces
> verify_pgp_signature() to be used by kernel subsystems (e.g. fsverity and
> IMA). Patch 12 is for testing of PGP signatures. Finally, patches 13-14
> allow loading a set of PGP keys from a supplied blob at boot time.
> 
> Changelog
> 
> v1 [4]:
> - Remove quiet_cmd_extract_certs (redundant, likely leftover from
>   conflict resolution)
> - Load PGP keys embedded in the kernel image within load_module_cert()
>   and load_system_certificate_list(), instead of using a separate initcall
> - Style bug fixes found by checkpatch.pl
> - Add <crypto/pgp.h> include in crypto/asymmetric_keys/pgp_preload.c, to
>   remove no previous prototype warning
> - Correctly check returned tfm in pgp_generate_fingerprint()
> - Fix printing message in pgp_generate_fingerprint()
> - Don't create a public key if the key blob does not contain a PGP key
>   packet
> - Remove unused pgp_pubkey_hash array
> - Set KEY_EFLAG_DIGITALSIG key flag if the key has the capability
> - Allow PGP_SIG_GENERAL_CERT_OF_UID_PUBKEY signature type (for key sigs)
> - Add is_key_sig parameter to pgp_sig_get_sig() to ensure the key
>   signature type is PGP_SIG_GENERAL_CERT_OF_UID_PUBKEY or
>   PGP_SIG_POSTITIVE_CERT_OF_UID_PUBKEY
> 
> v0 [3]:
> - style fixes
> - move include/linux/pgp.h and pgplib.h to crypto/asymmetric_keys
> - introduce verify_pgp_signature()
> - replace KEY_ALLOC_TRUSTED flag with KEY_ALLOC_BUILT_IN
> - don't fetch PGP subkeys
> - drop support for DSA
> - store number of MPIs in pgp_key_algo_p_num_mpi array
> - replace dynamic memory allocations with static ones in
>   pgp_generate_fingerprint()
> - store only keys with capability of verifying signatures
> - remember selection of PGP signature packet and don't repeat parsing
> - move search of the PGP key to verify the signature from the beginning
>   to the end of the verification process (to be similar with PKCS#7)
> - don't retry key search in the session keyring from the signature
>   verification code, let the caller pass the desired keyring
> - for the PGP signature test key type, retry the key search in the session
>   keyring
> - retry key search in restrict_link_by_signature() with a partial ID
>   (provided in the PGP signature)
> 
> [1] https://fedoraproject.org/wiki/Changes/FsVerityRPM
> [2] https://lore.kernel.org/linux-integrity/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git/log/?h=pgp-parser
> [4] https://lore.kernel.org/linux-integrity/20220111180318.591029-1-roberto.sassu@huawei.com/
> 
> David Howells (8):
>   PGPLIB: PGP definitions (RFC 4880)
>   PGPLIB: Basic packet parser
>   PGPLIB: Signature parser
>   KEYS: PGP data parser
>   KEYS: Provide PGP key description autogeneration
>   KEYS: PGP-based public key signature verification
>   PGP: Provide a key type for testing PGP signatures
>   KEYS: Provide a function to load keys from a PGP keyring blob
> 
> Roberto Sassu (6):
>   mpi: Introduce mpi_key_length()
>   rsa: add parser of raw format
>   KEYS: Retry asym key search with partial ID in
>     restrict_link_by_signature()
>   KEYS: Calculate key digest and get signature of the key
>   verification: introduce verify_pgp_signature()
>   KEYS: Introduce load_pgp_public_keyring()
> 
>  MAINTAINERS                             |   1 +
>  certs/Kconfig                           |  11 +
>  certs/Makefile                          |   7 +
>  certs/system_certificates.S             |  18 +
>  certs/system_keyring.c                  |  93 ++++
>  crypto/asymmetric_keys/Kconfig          |  38 ++
>  crypto/asymmetric_keys/Makefile         |  13 +
>  crypto/asymmetric_keys/pgp.h            | 206 ++++++++
>  crypto/asymmetric_keys/pgp_library.c    | 620 ++++++++++++++++++++++++
>  crypto/asymmetric_keys/pgp_parser.h     |  18 +
>  crypto/asymmetric_keys/pgp_preload.c    | 111 +++++
>  crypto/asymmetric_keys/pgp_public_key.c | 492 +++++++++++++++++++
>  crypto/asymmetric_keys/pgp_signature.c  | 505 +++++++++++++++++++
>  crypto/asymmetric_keys/pgp_test_key.c   | 129 +++++
>  crypto/asymmetric_keys/pgplib.h         |  74 +++
>  crypto/asymmetric_keys/restrict.c       |  10 +-
>  crypto/rsa.c                            |  14 +-
>  crypto/rsa_helper.c                     |  69 +++
>  include/crypto/internal/rsa.h           |   6 +
>  include/crypto/pgp.h                    |  36 ++
>  include/linux/mpi.h                     |   2 +
>  include/linux/verification.h            |  23 +
>  lib/crypto/mpi/mpicoder.c               |  33 +-
>  23 files changed, 2516 insertions(+), 13 deletions(-)
>  create mode 100644 crypto/asymmetric_keys/pgp.h
>  create mode 100644 crypto/asymmetric_keys/pgp_library.c
>  create mode 100644 crypto/asymmetric_keys/pgp_parser.h
>  create mode 100644 crypto/asymmetric_keys/pgp_preload.c
>  create mode 100644 crypto/asymmetric_keys/pgp_public_key.c
>  create mode 100644 crypto/asymmetric_keys/pgp_signature.c
>  create mode 100644 crypto/asymmetric_keys/pgp_test_key.c
>  create mode 100644 crypto/asymmetric_keys/pgplib.h
>  create mode 100644 include/crypto/pgp.h
>
Jarkko Sakkinen Aug. 19, 2024, 5:53 p.m. UTC | #4
On Sun Aug 18, 2024 at 7:57 PM EEST, Roberto Sassu wrote:
> The patch set includes two preliminary patches: patch 1 introduces
> mpi_key_length(), to get the number of bits and bytes of an MPI; patch 2
> introduces rsa_parse_priv_key_raw() and rsa_parse_pub_key_raw(), to parse
> an RSA key in RAW format if the ASN.1 parser returns an error.

I'd leave the discussion about these patches and delete the whole
paragraph. Preliminary patches happen they are not a goal and definitely
do not require a disclaimer in the cover letter.

>
> Patches 3-5 introduce the library necessary to parse PGP keys and
> signatures, whose support is added with patches 6-10. Patch 11 introduces
> verify_pgp_signature() to be used by kernel subsystems (e.g. fsverity and
> IMA). Patch 12 is for testing of PGP signatures. Finally, patches 13-14
> allow loading a set of PGP keys from a supplied blob at boot time.

Write a high-level description of the pieces that lead to solution and
leave patch numbers out.

I'd suggest rewrite the previous paragraphs simply as:

"PGP signatures center around verify_pgp_signature(). The patches
prepending it introduce helpers necessary to operate with the PGP
signatures."

That's all information they have.

BR, Jarkko
Jonathan McDowell Aug. 20, 2024, 2:12 p.m. UTC | #5
On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > 
> > > Support for PGP keys and signatures was proposed by David long time ago,
> > > before the decision of using PKCS#7 for kernel modules signatures
> > > verification was made. After that, there has been not enough interest to
> > > support PGP too.
> > 
> > You might want to update the RFC/bis references to RFC9580, which was
> > published last month and updates things.
> 
> Yes, makes sense (but probably isn't too much hassle to support more
> things for our purposes?)

I'm mostly suggesting that the comments/docs point to the latest
standard rather than the draft version, not changing to support the new
v6 keys.

> > Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> > idea. There are cryptographic issues with fingerprints etc there and I
> > can't think of a good reason you'd want the kernel to support them. The
> > same could probably be said of DSA key support too.
> 
> Uhm, if I remember correctly I encountered some old PGP keys used to
> verify RPM packages (need to check). DSA keys are not supported, since
> the algorithm is not in the kernel.

I would question the benefit gained from using obsolete key/signature
types for verification (I was involved in the process of Debian dropping
them back in *2010* which was later than it should have been). Dropping
the code for that path means a smaller attack surface/maintenance
overhead for something that isn't giving a benefit.

J.
Roberto Sassu Aug. 20, 2024, 2:14 p.m. UTC | #6
On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > > 
> > > > Support for PGP keys and signatures was proposed by David long time ago,
> > > > before the decision of using PKCS#7 for kernel modules signatures
> > > > verification was made. After that, there has been not enough interest to
> > > > support PGP too.
> > > 
> > > You might want to update the RFC/bis references to RFC9580, which was
> > > published last month and updates things.
> > 
> > Yes, makes sense (but probably isn't too much hassle to support more
> > things for our purposes?)
> 
> I'm mostly suggesting that the comments/docs point to the latest
> standard rather than the draft version, not changing to support the new
> v6 keys.
> 
> > > Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> > > idea. There are cryptographic issues with fingerprints etc there and I
> > > can't think of a good reason you'd want the kernel to support them. The
> > > same could probably be said of DSA key support too.
> > 
> > Uhm, if I remember correctly I encountered some old PGP keys used to
> > verify RPM packages (need to check). DSA keys are not supported, since
> > the algorithm is not in the kernel.
> 
> I would question the benefit gained from using obsolete key/signature
> types for verification (I was involved in the process of Debian dropping
> them back in *2010* which was later than it should have been). Dropping
> the code for that path means a smaller attack surface/maintenance
> overhead for something that isn't giving a benefit.

Ok, I agree to both!

Thanks

Roberto
Roberto Sassu Sept. 10, 2024, 2:36 p.m. UTC | #7
On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > > 
> > > > Support for PGP keys and signatures was proposed by David long time ago,
> > > > before the decision of using PKCS#7 for kernel modules signatures
> > > > verification was made. After that, there has been not enough interest to
> > > > support PGP too.
> > > 
> > > You might want to update the RFC/bis references to RFC9580, which was
> > > published last month and updates things.
> > 
> > Yes, makes sense (but probably isn't too much hassle to support more
> > things for our purposes?)
> 
> I'm mostly suggesting that the comments/docs point to the latest
> standard rather than the draft version, not changing to support the new
> v6 keys.
> 
> > > Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> > > idea. There are cryptographic issues with fingerprints etc there and I
> > > can't think of a good reason you'd want the kernel to support them. The
> > > same could probably be said of DSA key support too.
> > 
> > Uhm, if I remember correctly I encountered some old PGP keys used to
> > verify RPM packages (need to check). DSA keys are not supported, since
> > the algorithm is not in the kernel.
> 
> I would question the benefit gained from using obsolete key/signature
> types for verification (I was involved in the process of Debian dropping
> them back in *2010* which was later than it should have been). Dropping
> the code for that path means a smaller attack surface/maintenance
> overhead for something that isn't giving a benefit.

Removed support for v3 PGP signatures... but that broke openSUSE
Tumbleweed.

[  295.837602] PGPL: Signature packet with unhandled version 3

Roberto
Roberto Sassu Sept. 10, 2024, 2:51 p.m. UTC | #8
On Tue, 2024-09-10 at 16:36 +0200, Roberto Sassu wrote:
> On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> > On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > > > 
> > > > > Support for PGP keys and signatures was proposed by David long time ago,
> > > > > before the decision of using PKCS#7 for kernel modules signatures
> > > > > verification was made. After that, there has been not enough interest to
> > > > > support PGP too.
> > > > 
> > > > You might want to update the RFC/bis references to RFC9580, which was
> > > > published last month and updates things.
> > > 
> > > Yes, makes sense (but probably isn't too much hassle to support more
> > > things for our purposes?)
> > 
> > I'm mostly suggesting that the comments/docs point to the latest
> > standard rather than the draft version, not changing to support the new
> > v6 keys.
> > 
> > > > Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> > > > idea. There are cryptographic issues with fingerprints etc there and I
> > > > can't think of a good reason you'd want the kernel to support them. The
> > > > same could probably be said of DSA key support too.
> > > 
> > > Uhm, if I remember correctly I encountered some old PGP keys used to
> > > verify RPM packages (need to check). DSA keys are not supported, since
> > > the algorithm is not in the kernel.
> > 
> > I would question the benefit gained from using obsolete key/signature
> > types for verification (I was involved in the process of Debian dropping
> > them back in *2010* which was later than it should have been). Dropping
> > the code for that path means a smaller attack surface/maintenance
> > overhead for something that isn't giving a benefit.
> 
> Removed support for v3 PGP signatures... but that broke openSUSE
> Tumbleweed.
> 
> [  295.837602] PGPL: Signature packet with unhandled version 3

To add more context, this patch set adds the ability to the kernel to
verify the PGP signature of RPM packages against Linux distributions
PGP keys.

The purpose of this is to verify the authenticity of such RPM packages,
and to extract from them file digests, which are in turn used as
reference values for integrity check (appraisal) with IMA.

Roberto
Jonathan McDowell Sept. 10, 2024, 3:16 p.m. UTC | #9
On Tue, Sep 10, 2024 at 04:51:22PM +0200, Roberto Sassu wrote:
> On Tue, 2024-09-10 at 16:36 +0200, Roberto Sassu wrote:
> > On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> > > On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > > > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > > > > 
> > > > > > Support for PGP keys and signatures was proposed by David long time ago,
> > > > > > before the decision of using PKCS#7 for kernel modules signatures
> > > > > > verification was made. After that, there has been not enough interest to
> > > > > > support PGP too.
> > > > > 
> > > > > You might want to update the RFC/bis references to RFC9580, which was
> > > > > published last month and updates things.
> > > > 
> > > > Yes, makes sense (but probably isn't too much hassle to support more
> > > > things for our purposes?)
> > > 
> > > I'm mostly suggesting that the comments/docs point to the latest
> > > standard rather than the draft version, not changing to support the new
> > > v6 keys.
> > > 
> > > > > Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> > > > > idea. There are cryptographic issues with fingerprints etc there and I
> > > > > can't think of a good reason you'd want the kernel to support them. The
> > > > > same could probably be said of DSA key support too.
> > > > 
> > > > Uhm, if I remember correctly I encountered some old PGP keys used to
> > > > verify RPM packages (need to check). DSA keys are not supported, since
> > > > the algorithm is not in the kernel.
> > > 
> > > I would question the benefit gained from using obsolete key/signature
> > > types for verification (I was involved in the process of Debian dropping
> > > them back in *2010* which was later than it should have been). Dropping
> > > the code for that path means a smaller attack surface/maintenance
> > > overhead for something that isn't giving a benefit.
> > 
> > Removed support for v3 PGP signatures... but that broke openSUSE
> > Tumbleweed.

Is this a signature from a v3 key, or a v3 signature? Unfortunately
there are implementations which will issue a v3 signature even from a v4
key; IIRC this ambiguity has been cleared up in the updated RFC.

> > [  295.837602] PGPL: Signature packet with unhandled version 3
> 
> To add more context, this patch set adds the ability to the kernel to
> verify the PGP signature of RPM packages against Linux distributions
> PGP keys.

> The purpose of this is to verify the authenticity of such RPM packages,
> and to extract from them file digests, which are in turn used as
> reference values for integrity check (appraisal) with IMA.

I don't believe allowing a v3 *key* gives a useful verification that is
worth supporting. However unfortunately I think it sounds like support
for v3 signatures from v4 keys is necessary.

J.
Roberto Sassu Sept. 11, 2024, 9:55 a.m. UTC | #10
On Tue, 2024-09-10 at 16:16 +0100, Jonathan McDowell wrote:
> On Tue, Sep 10, 2024 at 04:51:22PM +0200, Roberto Sassu wrote:
> > On Tue, 2024-09-10 at 16:36 +0200, Roberto Sassu wrote:
> > > On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> > > > On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > > > > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > > > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > > > > > 
> > > > > > > Support for PGP keys and signatures was proposed by David long time ago,
> > > > > > > before the decision of using PKCS#7 for kernel modules signatures
> > > > > > > verification was made. After that, there has been not enough interest to
> > > > > > > support PGP too.
> > > > > > 
> > > > > > You might want to update the RFC/bis references to RFC9580, which was
> > > > > > published last month and updates things.
> > > > > 
> > > > > Yes, makes sense (but probably isn't too much hassle to support more
> > > > > things for our purposes?)
> > > > 
> > > > I'm mostly suggesting that the comments/docs point to the latest
> > > > standard rather than the draft version, not changing to support the new
> > > > v6 keys.
> > > > 
> > > > > > Also, I see support for v2 + v3 keys, and this doesn't seem like a good
> > > > > > idea. There are cryptographic issues with fingerprints etc there and I
> > > > > > can't think of a good reason you'd want the kernel to support them. The
> > > > > > same could probably be said of DSA key support too.
> > > > > 
> > > > > Uhm, if I remember correctly I encountered some old PGP keys used to
> > > > > verify RPM packages (need to check). DSA keys are not supported, since
> > > > > the algorithm is not in the kernel.
> > > > 
> > > > I would question the benefit gained from using obsolete key/signature
> > > > types for verification (I was involved in the process of Debian dropping
> > > > them back in *2010* which was later than it should have been). Dropping
> > > > the code for that path means a smaller attack surface/maintenance
> > > > overhead for something that isn't giving a benefit.
> > > 
> > > Removed support for v3 PGP signatures... but that broke openSUSE
> > > Tumbleweed.
> 
> Is this a signature from a v3 key, or a v3 signature? Unfortunately
> there are implementations which will issue a v3 signature even from a v4
> key; IIRC this ambiguity has been cleared up in the updated RFC.

Yes, it looks a v3 signature from a v4 key.


> > > [  295.837602] PGPL: Signature packet with unhandled version 3
> > 
> > To add more context, this patch set adds the ability to the kernel to
> > verify the PGP signature of RPM packages against Linux distributions
> > PGP keys.
> 
> > The purpose of this is to verify the authenticity of such RPM packages,
> > and to extract from them file digests, which are in turn used as
> > reference values for integrity check (appraisal) with IMA.
> 
> I don't believe allowing a v3 *key* gives a useful verification that is
> worth supporting. However unfortunately I think it sounds like support
> for v3 signatures from v4 keys is necessary.

Yes, after re-adding support for v3 signatures, openSUSE Tumbleweed is
back to normal, does IMA appraisal with RPM packages.

Thanks

Roberto