On Wed, 2019-04-24 at 14:33 +0000, Robert Holmes wrote:
> This patch completes commit 278311e417be ("kexec, KEYS: Make use of
> platform keyring for signature verify") which, while adding the
> platform keyring for bzImage verification, neglected to also add
> this keyring for module verification.
>
> As such, kernel modules signed with keys from the MokList variable
> were not successfully verified.
Using the platform keyring keys for verifying kernel modules was not
neglected, but rather intentional. This patch description should
clearly explain the reason for needing to verify kernel module
signatures based on the pre-boot keys. (Hint: verifying kernel
modules based on the pre-boot keys was previously rejected.)
Mimi
>
> Signed-off-by: Robert Holmes <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> kernel/module_signing.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/module_signing.c b/kernel/module_signing.c
> index 6b9a926fd86b..cf94220e9154 100644
> --- a/kernel/module_signing.c
> +++ b/kernel/module_signing.c
> @@ -49,6 +49,7 @@ int mod_verify_sig(const void *mod, struct load_info *info)
> {
> struct module_signature ms;
> size_t sig_len, modlen = info->len;
> + int ret;
>
> pr_devel("==>%s(,%zu)\n", __func__, modlen);
>
> @@ -82,8 +83,15 @@ int mod_verify_sig(const void *mod, struct load_info *info)
> return -EBADMSG;
> }
>
> - return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
> - VERIFY_USE_SECONDARY_KEYRING,
> - VERIFYING_MODULE_SIGNATURE,
> - NULL, NULL);
> + ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
> + VERIFY_USE_SECONDARY_KEYRING,
> + VERIFYING_MODULE_SIGNATURE,
> + NULL, NULL);
> + 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);
> + }
> + return ret;
> }
Hi,
On Thu, Apr 25, 2019 at 07:55:50AM -0400, Mimi Zohar wrote:
> On Wed, 2019-04-24 at 14:33 +0000, Robert Holmes wrote:
> > This patch completes commit 278311e417be ("kexec, KEYS: Make use of
> > platform keyring for signature verify") which, while adding the
> > platform keyring for bzImage verification, neglected to also add
> > this keyring for module verification.
> >
> > As such, kernel modules signed with keys from the MokList variable
> > were not successfully verified.
>
> Using the platform keyring keys for verifying kernel modules was not
> neglected, but rather intentional. This patch description should
> clearly explain the reason for needing to verify kernel module
> signatures based on the pre-boot keys. (Hint: verifying kernel
> modules based on the pre-boot keys was previously rejected.)
So the background for this patch is that Fedora, which carries the
lockdown patch set, recently regressed[0] with respect to user-signed
modules. Previously, we carried a patch that added all the pre-boot keys
to the secondary keyring. That way users could add a machine owner key
and use secure boot and lockdown with their self-signed 3rd party modules.
Since the pre-boot keys are now loaded into the platform keyring, I
suggested that Robert submit the patch upstream, but since the lockdown
patches aren't upstream perhaps it doesn't make much sense to pick this
up and Fedora should continue carrying it.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1701096
Regards,
Jeremy
> >
> > Signed-off-by: Robert Holmes <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: [email protected]
> > ---
> > kernel/module_signing.c | 16 ++++++++++++----
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/module_signing.c b/kernel/module_signing.c
> > index 6b9a926fd86b..cf94220e9154 100644
> > --- a/kernel/module_signing.c
> > +++ b/kernel/module_signing.c
> > @@ -49,6 +49,7 @@ int mod_verify_sig(const void *mod, struct load_info *info)
> > {
> > struct module_signature ms;
> > size_t sig_len, modlen = info->len;
> > + int ret;
> >
> > pr_devel("==>%s(,%zu)\n", __func__, modlen);
> >
> > @@ -82,8 +83,15 @@ int mod_verify_sig(const void *mod, struct load_info *info)
> > return -EBADMSG;
> > }
> >
> > - return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
> > - VERIFY_USE_SECONDARY_KEYRING,
> > - VERIFYING_MODULE_SIGNATURE,
> > - NULL, NULL);
> > + ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
> > + VERIFY_USE_SECONDARY_KEYRING,
> > + VERIFYING_MODULE_SIGNATURE,
> > + NULL, NULL);
> > + 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);
> > + }
> > + return ret;
> > }
>
On Thu, 2019-04-25 at 07:55 -0400, Mimi Zohar wrote:
> On Wed, 2019-04-24 at 14:33 +0000, Robert Holmes wrote:
> > This patch completes commit 278311e417be ("kexec, KEYS: Make use of
> > platform keyring for signature verify") which, while adding the
> > platform keyring for bzImage verification, neglected to also add
> > this keyring for module verification.
> >
> > As such, kernel modules signed with keys from the MokList variable
> > were not successfully verified.
>
> Using the platform keyring keys for verifying kernel modules was not
> neglected, but rather intentional. This patch description should
> clearly explain the reason for needing to verify kernel module
> signatures based on the pre-boot keys. (Hint: verifying kernel
> modules based on the pre-boot keys was previously rejected.)
To clarify here: most Linux systems use shim/mok to pivot the root of
trust away from the Secure Boot db variable to the new MokList/shim
built in keys. This makes the actual secure boot db outside the
expected Linux Kernel trust boundary *unless* the user has taken
ownership of the system and is actually using db for their own trusted
keys. This makes the policy for what pre-boot keys to trust within the
Linux boundary very complex, which is why we default to not using the
pre-boot keys at all.
James