Message ID | 20201120180426.922572-1-mic@digikod.net (mailing list archive) |
---|---|
Headers | show |
Series | Enable root to update the blacklist keyring | expand |
On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote: > Hi, > > This patch series mainly add a new configuration option to enable the > root user to load signed keys in the blacklist keyring. This keyring is > useful to "untrust" certificates or files. Enabling to safely update > this keyring without recompiling the kernel makes it more usable. I apologize for latency. This cycle has been difficult because of final cuts with the huge SGX patch set. I did skim through this and did not see anything striking (but it was a quick look). What would be easiest way to smoke test the changes? > Regards, > > Mickaël Salaün (9): > certs: Fix blacklisted hexadecimal hash string check > certs: Make blacklist_vet_description() more strict > certs: Factor out the blacklist hash creation > certs: Check that builtin blacklist hashes are valid > PKCS#7: Fix missing include > certs: Fix blacklist flag type confusion > certs: Allow root user to append signed hashes to the blacklist > keyring > certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID > tools/certs: Add print-cert-tbs-hash.sh > > MAINTAINERS | 2 + > certs/.gitignore | 1 + > certs/Kconfig | 10 + > certs/Makefile | 15 +- > certs/blacklist.c | 210 +++++++++++++----- > certs/system_keyring.c | 5 +- > crypto/asymmetric_keys/x509_public_key.c | 3 +- > include/keys/system_keyring.h | 14 +- > include/linux/verification.h | 2 + > scripts/check-blacklist-hashes.awk | 37 +++ > .../platform_certs/keyring_handler.c | 26 +-- > tools/certs/print-cert-tbs-hash.sh | 91 ++++++++ > 12 files changed, 335 insertions(+), 81 deletions(-) > create mode 100755 scripts/check-blacklist-hashes.awk > create mode 100755 tools/certs/print-cert-tbs-hash.sh > > > base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576 > -- > 2.29.2 > > /Jarkko
On 30/11/2020 03:40, Jarkko Sakkinen wrote: > On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote: >> Hi, >> >> This patch series mainly add a new configuration option to enable the >> root user to load signed keys in the blacklist keyring. This keyring is >> useful to "untrust" certificates or files. Enabling to safely update >> this keyring without recompiling the kernel makes it more usable. > > I apologize for latency. This cycle has been difficult because of > final cuts with the huge SGX patch set. > > I did skim through this and did not see anything striking (but it > was a quick look). > > What would be easiest way to smoke test the changes? An easy way to test it is to enable the second trusted keyring to dynamically load certificates in the kernel. Then we can create a hash of a valid certificate (but not loaded yet) and sign it as explained in tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded in the kernel, loading the blacklisted certificate will be denied. We can also test it with a PKCS#7 signature chain, either with the blacklist keyring itself, or with a signed dm-verity image. > >> Regards, >> >> Mickaël Salaün (9): >> certs: Fix blacklisted hexadecimal hash string check >> certs: Make blacklist_vet_description() more strict >> certs: Factor out the blacklist hash creation >> certs: Check that builtin blacklist hashes are valid >> PKCS#7: Fix missing include >> certs: Fix blacklist flag type confusion >> certs: Allow root user to append signed hashes to the blacklist >> keyring >> certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID >> tools/certs: Add print-cert-tbs-hash.sh >> >> MAINTAINERS | 2 + >> certs/.gitignore | 1 + >> certs/Kconfig | 10 + >> certs/Makefile | 15 +- >> certs/blacklist.c | 210 +++++++++++++----- >> certs/system_keyring.c | 5 +- >> crypto/asymmetric_keys/x509_public_key.c | 3 +- >> include/keys/system_keyring.h | 14 +- >> include/linux/verification.h | 2 + >> scripts/check-blacklist-hashes.awk | 37 +++ >> .../platform_certs/keyring_handler.c | 26 +-- >> tools/certs/print-cert-tbs-hash.sh | 91 ++++++++ >> 12 files changed, 335 insertions(+), 81 deletions(-) >> create mode 100755 scripts/check-blacklist-hashes.awk >> create mode 100755 tools/certs/print-cert-tbs-hash.sh >> >> >> base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576 >> -- >> 2.29.2 >> >> > > /Jarkko >
On Mon, Nov 30, 2020 at 09:23:59AM +0100, Mickaël Salaün wrote: > > On 30/11/2020 03:40, Jarkko Sakkinen wrote: > > On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote: > >> Hi, > >> > >> This patch series mainly add a new configuration option to enable the > >> root user to load signed keys in the blacklist keyring. This keyring is > >> useful to "untrust" certificates or files. Enabling to safely update > >> this keyring without recompiling the kernel makes it more usable. > > > > I apologize for latency. This cycle has been difficult because of > > final cuts with the huge SGX patch set. > > > > I did skim through this and did not see anything striking (but it > > was a quick look). > > > > What would be easiest way to smoke test the changes? > > An easy way to test it is to enable the second trusted keyring to > dynamically load certificates in the kernel. Then we can create a hash > of a valid certificate (but not loaded yet) and sign it as explained in > tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded > in the kernel, loading the blacklisted certificate will be denied. We > can also test it with a PKCS#7 signature chain, either with the > blacklist keyring itself, or with a signed dm-verity image. Thanks, looking into this once 5.11-rc1 is out. /Jarkko
Mickaël Salaün <mic@digikod.net> wrote: > > What would be easiest way to smoke test the changes? > > An easy way to test it is to enable the second trusted keyring to > dynamically load certificates in the kernel. Then we can create a hash > of a valid certificate (but not loaded yet) and sign it as explained in > tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded > in the kernel, loading the blacklisted certificate will be denied. We > can also test it with a PKCS#7 signature chain, either with the > blacklist keyring itself, or with a signed dm-verity image. It might also be possible to use the pkcs#7 test key type (CONFIG_PKCS7_TEST_KEY) to aid in that. David
On Fri, Dec 04, 2020 at 02:01:36PM +0000, David Howells wrote: > Mickaël Salaün <mic@digikod.net> wrote: > > > > What would be easiest way to smoke test the changes? > > > > An easy way to test it is to enable the second trusted keyring to > > dynamically load certificates in the kernel. Then we can create a hash > > of a valid certificate (but not loaded yet) and sign it as explained in > > tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded > > in the kernel, loading the blacklisted certificate will be denied. We > > can also test it with a PKCS#7 signature chain, either with the > > blacklist keyring itself, or with a signed dm-verity image. > > It might also be possible to use the pkcs#7 test key type > (CONFIG_PKCS7_TEST_KEY) to aid in that. > > David Thanks, note taken. /Jarkko