From: luca.boccassi@gmail.com
To: linux-security-module@vger.kernel.org
Cc: wufan@linux.microsoft.com, paul@paul-moore.com
Subject: [PATCH] ipe: allow secondary and platform keyrings to install/update policies
Date: Sat, 14 Sep 2024 01:48:40 +0200 [thread overview]
Message-ID: <20240913234840.1318655-1-luca.boccassi@gmail.com> (raw)
From: Luca Boccassi <bluca@debian.org>
The current policy management makes it impossible to use IPE
in a general purpose distribution. In such cases the users are not
building the kernel, the distribution is, and access to the private
key included in the trusted keyring is, for obvious reason, not
available.
This means that users have no way to enable IPE, since there will
be no built-in generic policy, and no access to the key to sign
updates validated by the trusted keyring.
Just as we do for dm-verity, kernel modules and more, allow the
secondary and platform keyrings to also validate policies. This
allows users enrolling their own keys in UEFI db or MOK to also
sign policies, and enroll them. This makes it sensible to enable
IPE in general purpose distributions, as it becomes usable by
any user wishing to do so. Keys in these keyrings can already
load kernels and kernel modules, so there is no security
downgrade.
Signed-off-by: Luca Boccassi <bluca@debian.org>
---
security/ipe/policy.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/security/ipe/policy.c b/security/ipe/policy.c
index d8e7db857a2e..cac304dc86c2 100644
--- a/security/ipe/policy.c
+++ b/security/ipe/policy.c
@@ -169,9 +169,15 @@ struct ipe_policy *ipe_new_policy(const char *text, size_t textlen,
goto err;
}
- rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len, NULL,
+ rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len,
+ VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_UNSPECIFIED_SIGNATURE,
set_pkcs7_data, new);
+ if (rc == -ENOKEY)
+ rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len,
+ VERIFY_USE_PLATFORM_KEYRING,
+ VERIFYING_UNSPECIFIED_SIGNATURE,
+ set_pkcs7_data, new);
if (rc)
goto err;
} else {
--
2.39.2
next reply other threads:[~2024-09-13 23:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 23:48 luca.boccassi [this message]
2024-09-15 4:27 ` [PATCH] ipe: allow secondary and platform keyrings to install/update policies Fan Wu
2024-09-15 9:14 ` Luca Boccassi
2024-09-15 9:11 ` [PATCH v2] " luca.boccassi
2024-09-20 2:02 ` Serge E. Hallyn
2024-09-20 7:54 ` Luca Boccassi
2024-09-20 13:02 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240913234840.1318655-1-luca.boccassi@gmail.com \
--to=luca.boccassi@gmail.com \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=wufan@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).