Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #78178 > unrolled thread
| Started by | наб <nabijaczleweli@nabijaczleweli.xyz> |
|---|---|
| First post | 2023-02-03 05:10 +0100 |
| Last post | 2023-03-31 14:40 +0200 |
| Articles | 4 — 1 participant |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#1030200: linux-image-6.1.0-3-amd64: "Loading of module with unavailable key is rejected", /proc/keys says key is loaded; system unbootable наб <nabijaczleweli@nabijaczleweli.xyz> - 2023-02-03 05:10 +0100
Bug#1030200: linux-image-6.1.0-3-amd64: "Loading of module with unavailable key is rejected", /proc/keys says key is loaded; system unbootable наб <nabijaczleweli@nabijaczleweli.xyz> - 2023-03-25 03:50 +0100
Bug#1030200: linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0 наб <nabijaczleweli@nabijaczleweli.xyz> - 2023-03-31 03:20 +0200
Bug#1030200: linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0 наб <nabijaczleweli@nabijaczleweli.xyz> - 2023-03-31 14:40 +0200
| From | наб <nabijaczleweli@nabijaczleweli.xyz> |
|---|---|
| Date | 2023-02-03 05:10 +0100 |
| Subject | Bug#1030200: linux-image-6.1.0-3-amd64: "Loading of module with unavailable key is rejected", /proc/keys says key is loaded; system unbootable |
| Message-ID | <FUVyF-32Ya-1@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
Turns out Debian .config includes dyndbg, so I tried booting with dyndbg="+pfm; module iommu =_; module acpi =_" log_buf_len=4M and got A Result. In both cases I broke as in the initrd (too late, it seems), echo MARK > /dev/kmsg modprobe zfs echo MARK > /dev/kmsg modprobe vfat echo MARK > /dev/kmsg then i turned off dyndbg. dmesg and journalctl -b in resp. files (all compressed now, sorry; dmesgs are 4M and journals 6M per). dkms-$kver is /lib/modules/.../dkms (with the DKMSed .kos) and I also added vfat.ko for reference, but that's, naturally, from the package. Interesting bits: /both/ logs have this exact fragment (time is different, of course): [ 0.756794] integrity: Loaded X.509 cert 'babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6' [ 0.756794] integrity: Loading X.509 certificate: UEFI:db [ 0.756795] asymmetric_keys:asymmetric_key_preparse: Trying parser 'x509' [ 0.756834] x509_key_parser:x509_note_sig_algo: X.509: PubKey Algo: 15 [ 0.756955] x509_key_parser:x509_process_extension: X.509: Extension: 44 [ 0.756973] x509_key_parser:x509_process_extension: X.509: Extension: 71 [ 0.756987] x509_key_parser:x509_note_OID: X.509: Unknown OID: [551] 2.16.840.1.113730.1.1 [ 0.756995] x509_key_parser:x509_process_extension: X.509: Extension: 98 [ 0.757013] x509_key_parser:x509_process_extension: X.509: Extension: 72 [ 0.757033] x509_key_parser:x509_process_extension: X.509: Extension: 65 [ 0.757052] x509_key_parser:x509_process_extension: X.509: Extension: 68 [ 0.757071] x509_key_parser:x509_process_extension: X.509: Extension: 64 [ 0.757072] x509_key_parser:x509_process_extension: X.509: subjkeyid 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 [ 0.757087] x509_key_parser:x509_note_tbs_certificate: X.509: x509_note_tbs_certificate(,4,04,8,646)! [ 0.757106] x509_key_parser:x509_note_signature: X.509: Signature: alg=15, size=257 [ 0.757117] x509_key_parser:x509_akid_note_kid: X.509: AKID: keyid: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 [ 0.757118] x509_key_parser:x509_akid_note_kid: X.509: authkeyid 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1 [ 0.757271] asymmetric_keys:asymmetric_key_preparse: Parser recognised the format (ret 0) [ 0.757274] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1' [ 0.757687] integrity:load_uefi_certs: integrity: dbx variable wasn't found [ 0.758064] integrity:load_uefi_certs: integrity: mokx variable wasn't found [ 0.758435] integrity:load_moklist_certs: integrity: MokListRT variable wasn't found And when loading vfat, both have this (uargs and the mokx digest are different, that's expected): [ 37.135400] MARK [ 40.188878] main:__do_sys_finit_module: finit_module: fd=3, uargs=0000000061bb63d7, flags=0 [ 40.190252] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#32a0287f841a036fa393c1e065c43ae6b2422643311e301c0603550403131544656269616e2053656375 26081 726520426f6f74204341) [ 40.190256] asymmetric_keys:find_asymmetric_key: Look up: "ex:32a0287f841a036fa393c1e065c43ae6b2422643311e301c0603550403131544656269616e2053656375726520426f6f74204341" [ 40.191459] signing:mod_is_hash_blacklisted: 188779 digest: ba2fe77f90be3c8ca26422359c20213f9dd0f68c9b9bbd1f54f47e77e6e124cf [ 40.191470] main:layout_sections: Core section allocation order: [ 40.191472] main:layout_sections: .text [ 40.191473] main:layout_sections: .text.unlikely [ 40.191474] main:layout_sections: .exit.text But when searching for 7e7595e2f222646de0dcfee034bd181ed37844b7 (to get the first instance of a DKMSed module being loaded; that bit also matches the cert serial, apparently), 6.0.0-5-amd64 says this: [ 1.757036] main:__do_sys_finit_module: finit_module: fd=3, uargs=00000000160ad9df, flags=0 [ 1.758562] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f7731) [ 1.758566] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a" [ 1.758572] asymmetric_keys:find_asymmetric_key: Request for key 'ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a' err -11 [ 1.759871] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f7731) [ 1.759872] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a" [ 1.761421] signing:mod_is_hash_blacklisted: 233242 digest: f4bef7055edd1138e68926ab010f9925dd88680732d7f47042b879a7fd9ef66a [ 1.761434] spl: loading out-of-tree module taints kernel. [ 1.761443] main:layout_sections: Core section allocation order: [ 1.761444] main:layout_sections: .text [ 1.761445] main:layout_sections: .text.unlikely But 6.1.0-3-amd64 says this: [ 1.733680] main:__do_sys_finit_module: finit_module: fd=3, uargs=00000000822587e4, flags=0 [ 1.736878] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b 27399 0c024442310f300d06035504070c064b72616b6f7731) [ 1.736881] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d060355040 27400 70c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a" [ 1.736887] asymmetric_keys:find_asymmetric_key: Request for key 'ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06 27401 035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a' err -11 [ 1.736890] Loading of module with unavailable key is rejected What this means is unclear to me, but it's odd. наб
[toc] | [next] | [standalone]
| From | наб <nabijaczleweli@nabijaczleweli.xyz> |
|---|---|
| Date | 2023-03-25 03:50 +0100 |
| Message-ID | <Gd28F-eTm6-3@gated-at.bofh.it> |
| In reply to | #78178 |
[Multipart message — attachments visible in raw view] — view raw
If anyone has a faintest idea so as to what the problem may be, please help; the only vaguely-related config change is INTEGRITY_MACHINE_KEYRING going from unset to y, but that shouldn't(! not that it doesn't, the code is an enigma to me, but as i understand it and as i read the kconfig, it shouldn't) change anything if you aren't a MOK user, and I'm not. Please advise. наб
[toc] | [prev] | [next] | [standalone]
| From | наб <nabijaczleweli@nabijaczleweli.xyz> |
|---|---|
| Date | 2023-03-31 03:20 +0200 |
| Subject | Bug#1030200: linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0 |
| Message-ID | <GfbAR-ggVo-1@gated-at.bofh.it> |
| In reply to | #78593 |
[Multipart message — attachments visible in raw view] — view raw
Control: retitle -1 linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0
Control: tags -1 + patch
In many ways I went wrong by limiting my search to the linux checkout,
and not the source package.
Upstream kernel/module/signing.c#mod_verify_sig() ends with:
return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
}
In 6.1.20-1 it ends with:
ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
pr_devel("verify_pkcs7_signature() = %d\n", ret);
/* checking hash of module is in blacklist */
if (!ret)
ret = mod_is_hash_blacklisted(mod, wholelen);
return ret;
}
But in 6.0.12-1 it ended with (excuse patch format):
@@ -116,6 +116,13 @@ int mod_verify_sig(const void *mod, stru
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
pr_devel("verify_pkcs7_signature() = %d\n", ret);
+ if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
+ ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+ VERIFY_USE_PLATFORM_KEYRING,
+ VERIFYING_MODULE_SIGNATURE,
+ NULL, NULL);
+ pr_devel("verify_pkcs7_signature() = %d\n", ret);
+ }
/* checking hash of module is in blacklist */
if (!ret)
So in 6.0.x, debian carried a patch
(features/all/db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch),
which was dropped in
commit 9aa15a22634335db058256092572fd2725ca674b
Author: Luca Boccassi <bluca@debian.org>
Date: Thu Oct 13 23:23:28 2022 +0100
Drop obsolete MODSIGN patches
Upstream loads keys from MoK, no need for the out-of-tree patches anymore
and that commit is included in all debian/6.1* tags on salsa.
On Fri, Mar 31, 2023 at 01:45:08AM +0200, наб wrote:
> keys-6.0:19c0bfbd I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 1
> keys-6.1:29a13614 I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 2
>
> Note how there's somehow a second key in .secondary_trusted_keys.
> Whether this means something or is an accounting difference
> is unclear to me at this time.
That patch was added for #935945, which also notes a method of having
keyctl dump keyring contents, which I couldn't figure out.
However, on 6.1 (dumped from the initrd):
# keyctl list %:.builtin_trusted_keys
2 keys in keyring:
672487752: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
874879581: ---lswrv 0 0 asymmetric: Debian Secure Boot Signer 2022 - linux: 14011249c2675ea8e5148542202005810584b25f
# keyctl list %:.platform
4 keys in keyring:
374796544: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6
116765678: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot DB 2023: 00befacaa0
20694596: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot CA: 00befa30fa
946336801: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
# keyctl list %:.secondary_trusted_keys
2 keys in keyring:
624245999: ---lswrv 0 0 keyring: .builtin_trusted_keys
996684961: ---lswrv 0 0 keyring: .machine
# keyctl list %:.machine
keyring is empty
And on 6.0:
# keyctl list %:.builtin_trusted_keys
Please touch the device.
2 keys in keyring:
417373165: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
726407570: ---lswrv 0 0 asymmetric: Debian Secure Boot Signer 2022 - linux: 14011249c2675ea8e5148542202005810584b25f
# keyctl list %:.platform
4 keys in keyring:
699875236: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6
885300684: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot DB 2023: 00befacaa0
927553785: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot CA: 00befa30fa
707478853: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
# keyctl list %:.secondary_trusted_keys
1 key in keyring:
889210333: ---lswrv 0 0 keyring: .builtin_trusted_keys
# keyctl list %:.machine
Can't find 'keyring:.machine'
So, to summarise:
6.0 upstream trusts the built-in keys,
and carries a patch to trust the platform
6.1 upstream trusts the built-in keys and MOK
(debian just enables trusting MOK always)
See certs/system_keyring.c:
static __init struct key_restriction *get_builtin_and_secondary_restriction(void)
{
struct key_restriction *restriction;
restriction = kzalloc(sizeof(struct key_restriction), GFP_KERNEL);
if (!restriction)
panic("Can't allocate secondary trusted keyring restriction\n");
if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
restriction->check = restrict_link_by_builtin_secondary_and_machine;
else
restriction->check = restrict_link_by_builtin_and_secondary_trusted;
return restriction;
}
void __init set_machine_trusted_keys(struct key *keyring)
{
machine_trusted_keys = keyring;
if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
panic("Can't link (machine) trusted keyrings\n");
}
/**
* restrict_link_by_builtin_secondary_and_machine - Restrict keyring addition.
* @dest_keyring: Keyring being linked to.
* @type: The type of key being added.
* @payload: The payload of the new key.
* @restrict_key: A ring of keys that can be used to vouch for the new cert.
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in either the built-in, the secondary, or
* the machine keyrings.
*/
int restrict_link_by_builtin_secondary_and_machine(
struct key *dest_keyring,
const struct key_type *type,
const union key_payload *payload,
struct key *restrict_key)
{
if (machine_trusted_keys && type == &key_type_keyring &&
dest_keyring == secondary_trusted_keys &&
payload == &machine_trusted_keys->payload)
/* Allow the machine keyring to be added to the secondary */
return 0;
return restrict_link_by_builtin_and_secondary_trusted(dest_keyring, type,
payload, restrict_key);
}
security/integrity/digsig.c:
static int __init __integrity_init_keyring(const unsigned int id,
key_perm_t perm,
struct key_restriction *restriction)
{
const struct cred *cred = current_cred();
int err = 0;
keyring[id] = keyring_alloc(keyring_name[id], KUIDT_INIT(0),
KGIDT_INIT(0), cred, perm,
KEY_ALLOC_NOT_IN_QUOTA, restriction, NULL);
if (IS_ERR(keyring[id])) {
err = PTR_ERR(keyring[id]);
pr_info("Can't allocate %s keyring (%d)\n",
keyring_name[id], err);
keyring[id] = NULL;
} else {
if (id == INTEGRITY_KEYRING_PLATFORM)
set_platform_trusted_keys(keyring[id]);
if (id == INTEGRITY_KEYRING_MACHINE && trust_moklist())
set_machine_trusted_keys(keyring[id]);
if (id == INTEGRITY_KEYRING_IMA)
load_module_cert(keyring[id]);
}
return err;
}
(features/all/db-mok-keyring/trust-machine-keyring-by-default.patch
makes trust_moklist() be always true, hence why I see .machine linked
to secondary even though I don't use MOK).
And compare this with how the non-MOK restriction works:
/**
* restrict_link_by_builtin_and_secondary_trusted - Restrict keyring
* addition by both builtin and secondary keyrings
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in either the built-in or the secondary system
* keyrings.
*/
int restrict_link_by_builtin_and_secondary_trusted(
struct key *dest_keyring,
const struct key_type *type,
const union key_payload *payload,
struct key *restrict_key)
{
/* If we have a secondary trusted keyring, then that contains a link
* through to the builtin keyring and the search will follow that link.
*/
if (type == &key_type_keyring &&
dest_keyring == secondary_trusted_keys &&
payload == &builtin_trusted_keys->payload)
/* Allow the builtin keyring to be added to the secondary */
return 0;
return restrict_link_by_signature(dest_keyring, type, payload,
secondary_trusted_keys);
}
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
void __init set_platform_trusted_keys(struct key *keyring)
{
platform_trusted_keys = keyring;
}
#endif
It's relatively trivial to port what's done with the machine keyring
here to the platform keyring, but that'd extend the reach of the
platform keyring more than desired
(DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING,
pkcs7_preparse()).
But most places that use VERIFY_USE_SECONDARY_KEYRING also check for
VERIFY_USE_PLATFORM_KEYRING right after, so dropping that patch is
baffling to me, since it's very much a regression, and it was spelled in
an upstream-endorsed way (indeed, look no further than
kexec_kernel_verify_pe_sig() which is exactly the same).
Attaching, essentially, a re-generated version of the old patch;
I'll build-test and post a Salsa MR tomorrow.
Best,
наб
[toc] | [prev] | [next] | [standalone]
| From | наб <nabijaczleweli@nabijaczleweli.xyz> |
|---|---|
| Date | 2023-03-31 14:40 +0200 |
| Subject | Bug#1030200: linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0 |
| Message-ID | <GfmcV-gnFe-1@gated-at.bofh.it> |
| In reply to | #78654 |
[Multipart message — attachments visible in raw view] — view raw
https://salsa.debian.org/kernel-team/linux/-/merge_requests/691 наб
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web