* [PATCH RFC 08/12] integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_secondary_trusted_or_ca
From: Eric Snowberg @ 2021-07-07 2:43 UTC (permalink / raw)
To: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert, davem,
jarkko, jmorris, serge
Cc: eric.snowberg, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
Set the restriction check for INTEGRITY_KEYRING_MOK keys to
restrict_link_by_secondary_trusted_or_ca. This will only allow keys
into the mok keyring that are either a CA or trusted by a key contained
within the secondary trusted keyring.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
security/integrity/digsig.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 56800a5f1e10..07547f1a4806 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -140,6 +140,11 @@ int __init integrity_init_keyring(const unsigned int id)
return -ENOMEM;
restriction->check = restrict_link_to_ima;
+ if (id == INTEGRITY_KEYRING_MOK)
+ restriction->check = restrict_link_by_secondary_trusted_or_ca;
+ else
+ restriction->check = restrict_link_to_ima;
+
perm |= KEY_USR_WRITE;
out:
--
2.18.4
^ permalink raw reply related
* [PATCH RFC 11/12] integrity: move keys from the mok keyring into the secondary keyring
From: Eric Snowberg @ 2021-07-07 2:44 UTC (permalink / raw)
To: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert, davem,
jarkko, jmorris, serge
Cc: eric.snowberg, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
Keys added to the mok keyring are only stored there temporarily. After
passing the permissions check, move the key from the mok keyring into
the secondary trusted keyring.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
security/integrity/digsig.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 07547f1a4806..e301cee037bf 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -175,8 +175,13 @@ static int __init integrity_add_key(const unsigned int id, const void *data,
rc = PTR_ERR(key);
pr_err("Problem loading X.509 certificate %d\n", rc);
} else {
- pr_notice("Loaded X.509 cert '%s'\n",
- key_ref_to_ptr(key)->description);
+ if (id == INTEGRITY_KEYRING_MOK)
+ rc = move_to_trusted_secondary_keyring(key_ref_to_ptr(key),
+ keyring[id]);
+ else
+ pr_notice("Loaded X.509 cert '%s'\n",
+ key_ref_to_ptr(key)->description);
+
key_ref_put(key);
}
--
2.18.4
^ permalink raw reply related
* [PATCH RFC 06/12] integrity: Trust mok keys if MokListTrustedRT found
From: Eric Snowberg @ 2021-07-07 2:43 UTC (permalink / raw)
To: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert, davem,
jarkko, jmorris, serge
Cc: eric.snowberg, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
A new MOK variable called MokListTrustedRT has been introduced in shim.
When this UEFI variable is set, it indicates the end-user has made the
decision themself that they wish to trust MOK keys within the Linux
trust boundary. It is not an error if this variable does not exist. If
it does not exist, the MOK keys should not be trusted within the kernel.
MOK variables are mirrored from Boot Services to Runtime Services. When
shim sees the new MokTML BS variable, it will create a new variable
(before Exit Boot Services is called) called MokListTrustedRT without
EFI_VARIABLE_NON_VOLATILE set. Following Exit Boot Services, UEFI
variables can only be set and created with SetVariable if both
EFI_VARIABLE_RUNTIME_ACCESS & EFI_VARIABLE_NON_VOLATILE are set.
Therefore, this can not be defeated by simply creating a MokListTrustedRT
variable from Linux, the existence of EFI_VARIABLE_NON_VOLATILE will cause
uefi_check_trust_mok_keys to return false.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
.../integrity/platform_certs/mok_keyring.c | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/security/integrity/platform_certs/mok_keyring.c b/security/integrity/platform_certs/mok_keyring.c
index 2b0d17caf8fd..666fa355996d 100644
--- a/security/integrity/platform_certs/mok_keyring.c
+++ b/security/integrity/platform_certs/mok_keyring.c
@@ -5,8 +5,11 @@
* Copyright (c) 2021, Oracle and/or its affiliates.
*/
+#include <linux/efi.h>
#include "../integrity.h"
+bool trust_mok;
+
static __init int mok_keyring_init(void)
{
int rc;
@@ -24,3 +27,38 @@ void __init destroy_mok_keyring(void)
{
return integrity_destroy_keyring(INTEGRITY_KEYRING_MOK);
}
+
+/*
+ * Try to load the MokListTrustedRT UEFI variable to see if we should trust
+ * the mok keys within the kernel. It is not an error if this variable
+ * does not exist. If it does not exist, mok keys should not be trusted
+ * within the kernel.
+ */
+static __init bool uefi_check_trust_mok_keys(void)
+{
+ efi_status_t status;
+ unsigned int mtrust = 0;
+ unsigned long size = sizeof(mtrust);
+ efi_guid_t guid = EFI_SHIM_LOCK_GUID;
+ u32 attr;
+
+ status = efi.get_variable(L"MokListTrustedRT", &guid, &attr, &size, &mtrust);
+
+ /*
+ * The EFI_VARIABLE_NON_VOLATILE check is to verify MokListTrustedRT
+ * was set thru shim mirrioring and not by a user from the host os.
+ * According to the UEFI spec, once EBS is performed, SetVariable()
+ * will succeed only when both EFI_VARIABLE_RUNTIME_ACCESS &
+ * EFI_VARIABLE_NON_VOLATILE are set.
+ */
+ return (status == EFI_SUCCESS && (!(attr & EFI_VARIABLE_NON_VOLATILE)));
+}
+
+static __init int mok_keyring_trust_setup(void)
+{
+ if (uefi_check_trust_mok_keys())
+ trust_mok = true;
+ return 0;
+}
+
+late_initcall(mok_keyring_trust_setup);
--
2.18.4
^ permalink raw reply related
* [PATCH RFC 07/12] integrity: add add_to_mok_keyring
From: Eric Snowberg @ 2021-07-07 2:43 UTC (permalink / raw)
To: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert, davem,
jarkko, jmorris, serge
Cc: eric.snowberg, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
Add the ability to load MOK keys to the mok keyring. If the permssions
do not allow the key to be added to the MOK keyring this is not an
error, add it to the platform keyring instead.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
security/integrity/integrity.h | 4 ++++
.../integrity/platform_certs/mok_keyring.c | 21 +++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 5126c80bd0d4..68720fa6454f 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -284,6 +284,7 @@ integrity_audit_log_start(struct audit_context *ctx, gfp_t gfp_mask, int type)
void __init add_to_platform_keyring(const char *source, const void *data,
size_t len);
void __init destroy_mok_keyring(void);
+void __init add_to_mok_keyring(const char *source, const void *data, size_t len);
#else
static inline void __init add_to_platform_keyring(const char *source,
const void *data, size_t len)
@@ -292,4 +293,7 @@ static inline void __init add_to_platform_keyring(const char *source,
static inline void __init destroy_mok_keyring(void)
{
}
+void __init add_to_mok_keyring(const char *source, const void *data, size_t len)
+{
+}
#endif
diff --git a/security/integrity/platform_certs/mok_keyring.c b/security/integrity/platform_certs/mok_keyring.c
index 666fa355996d..a5644a8a834c 100644
--- a/security/integrity/platform_certs/mok_keyring.c
+++ b/security/integrity/platform_certs/mok_keyring.c
@@ -28,6 +28,27 @@ void __init destroy_mok_keyring(void)
return integrity_destroy_keyring(INTEGRITY_KEYRING_MOK);
}
+void __init add_to_mok_keyring(const char *source, const void *data, size_t len)
+{
+ key_perm_t perm;
+ int rc;
+
+ perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW;
+ rc = integrity_load_cert(INTEGRITY_KEYRING_MOK, source, data, len, perm);
+
+ /*
+ * If the mok keyring restrictions prevented the cert from loading,
+ * this is not an error. Just load it into the platform keyring
+ * instead.
+ */
+ if (rc)
+ rc = integrity_load_cert(INTEGRITY_KEYRING_PLATFORM, source,
+ data, len, perm);
+
+ if (rc)
+ pr_info("Error adding keys to mok keyring %s\n", source);
+}
+
/*
* Try to load the MokListTrustedRT UEFI variable to see if we should trust
* the mok keys within the kernel. It is not an error if this variable
--
2.18.4
^ permalink raw reply related
* [PATCH RFC 10/12] integrity: add new keyring handler
From: Eric Snowberg @ 2021-07-07 2:44 UTC (permalink / raw)
To: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert, davem,
jarkko, jmorris, serge
Cc: eric.snowberg, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
Add a new keyring handler for the mok keyring. If the Secondary trusted
keyring is enabled and the end-user trusts the MOK keys, this new
keyring handler is used.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
.../integrity/platform_certs/keyring_handler.c | 17 ++++++++++++++++-
.../integrity/platform_certs/keyring_handler.h | 5 +++++
security/integrity/platform_certs/load_uefi.c | 4 ++--
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index 5604bd57c990..b6daeb1e3de5 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -66,7 +66,7 @@ static __init void uefi_revocation_list_x509(const char *source,
/*
* Return the appropriate handler for particular signature list types found in
- * the UEFI db and MokListRT tables.
+ * the UEFI db tables.
*/
__init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
{
@@ -75,6 +75,21 @@ __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
return 0;
}
+/*
+ * Return the appropriate handler for particular signature list types found in
+ * the MokListRT tables.
+ */
+__init efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type)
+{
+ if (efi_guidcmp(*sig_type, efi_cert_x509_guid) == 0) {
+ if (IS_ENABLED(CONFIG_SECONDARY_TRUSTED_KEYRING) && trust_moklist())
+ return add_to_mok_keyring;
+ else
+ return add_to_platform_keyring;
+ }
+ return 0;
+}
+
/*
* Return the appropriate handler for particular signature list types found in
* the UEFI dbx and MokListXRT tables.
diff --git a/security/integrity/platform_certs/keyring_handler.h b/security/integrity/platform_certs/keyring_handler.h
index 2462bfa08fe3..284558f30411 100644
--- a/security/integrity/platform_certs/keyring_handler.h
+++ b/security/integrity/platform_certs/keyring_handler.h
@@ -24,6 +24,11 @@ void blacklist_binary(const char *source, const void *data, size_t len);
*/
efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type);
+/*
+ * Return the handler for particular signature list types found in the mok.
+ */
+efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type);
+
/*
* Return the handler for particular signature list types found in the dbx.
*/
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index 94faa4b32441..f021dd81f080 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -94,7 +94,7 @@ static int __init load_moklist_certs(void)
rc = parse_efi_signature_list("UEFI:MokListRT (MOKvar table)",
mokvar_entry->data,
mokvar_entry->data_size,
- get_handler_for_db);
+ get_handler_for_mok);
/* All done if that worked. */
if (!rc)
return rc;
@@ -109,7 +109,7 @@ static int __init load_moklist_certs(void)
mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status);
if (mok) {
rc = parse_efi_signature_list("UEFI:MokListRT",
- mok, moksize, get_handler_for_db);
+ mok, moksize, get_handler_for_mok);
kfree(mok);
if (rc)
pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
--
2.18.4
^ permalink raw reply related
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Christoph Hellwig @ 2021-07-07 6:46 UTC (permalink / raw)
To: Eric Snowberg
Cc: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert, davem,
jarkko, jmorris, serge, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
On Tue, Jul 06, 2021 at 10:43:51PM -0400, Eric Snowberg wrote:
> This is a follow up to the "Add additional MOK vars" [1] series I
> previously sent. This series incorporates the feedback given
> both publicly on the mailing list and privately from Mimi. This
> series just focuses on getting end-user keys into the kernel trust
> boundary.
WTF is MOK?
^ permalink raw reply
* RE: [PATCH] ima: Support euid keyword for buffer measurement
From: Roberto Sassu @ 2021-07-07 7:15 UTC (permalink / raw)
To: Lakshmi Ramasubramanian, zohar@linux.ibm.com
Cc: tusharsu@linux.microsoft.com, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <2996f5ae-d76f-5fc9-bf90-857d4fc6644a@linux.microsoft.com>
> From: Lakshmi Ramasubramanian [mailto:nramas@linux.microsoft.com]
> Sent: Tuesday, July 6, 2021 9:30 PM
> On 7/5/2021 4:56 AM, Roberto Sassu wrote:
>
> Hi Roberto,
>
> > This patch makes the 'euid' keyword available for buffer measurement rules,
> > in the same way as for other rules. Currently, there is only support for
> > the 'uid' keyword.
> >
> > With this change, buffer measurement (or non-measurement) can depend
> also
> > on the process effective UID.
>
> Who (kernel component) will be using this?
Hi Lakshmi
I'm using it in a (not yet submitted) test for digest lists.
It is in a dont_measure rule to try to unload a digest list
without measurement and to check that this is not allowed
if the digest list was measured at addition time (to ensure
completeness of information).
> Maybe you could make this change as part of the patch set in which the
> above "euid" support will be used.
I wanted to send the digest lists patch set without anything
else. I could resend the patch as part of that patch set if it is
preferred.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
> thanks,
> -lakshmi
>
> >
> > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > ---
> > security/integrity/ima/ima_policy.c | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/security/integrity/ima/ima_policy.c
> b/security/integrity/ima/ima_policy.c
> > index fd5d46e511f1..fdaa030fb04b 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -480,6 +480,16 @@ static bool ima_match_rule_data(struct
> ima_rule_entry *rule,
> > if ((rule->flags & IMA_UID) && !rule->uid_op(cred->uid, rule->uid))
> > return false;
> >
> > + if (rule->flags & IMA_EUID) {
> > + if (has_capability_noaudit(current, CAP_SETUID)) {
> > + if (!rule->uid_op(cred->euid, rule->uid)
> > + && !rule->uid_op(cred->suid, rule->uid)
> > + && !rule->uid_op(cred->uid, rule->uid))
> > + return false;
> > + } else if (!rule->uid_op(cred->euid, rule->uid))
> > + return false;
> > + }
> > +
> > switch (rule->func) {
> > case KEY_CHECK:
> > if (!rule->keyrings)
> > @@ -1153,7 +1163,7 @@ static bool ima_validate_rule(struct
> ima_rule_entry *entry)
> > if (entry->action & ~(MEASURE | DONT_MEASURE))
> > return false;
> >
> > - if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
> > + if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_EUID |
> IMA_PCR |
> > IMA_LABEL))
> > return false;
> >
> >
^ permalink raw reply
* Re: [PATCH] smack: mark 'smack_enabled' global variable as __initdata
From: Austin Kim @ 2021-07-07 10:14 UTC (permalink / raw)
To: casey, James Morris, Serge E. Hallyn
Cc: linux-security-module, Linux Kernel Mailing List, kernel-team
In-Reply-To: <20210629134144.GA1168@raspberrypi>
2021년 6월 29일 (화) 오후 10:41, Austin Kim <austindh.kim@gmail.com>님이 작성:
>
> From: Austin Kim <austin.kim@lge.com>
>
> Mark 'smack_enabled' as __initdata
> since it is only used during initialization code.
>
> Signed-off-by: Austin Kim <austin.kim@lge.com>
> ---
> security/smack/smack.h | 2 +-
> security/smack/smack_lsm.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index c3cfbdf4944a..99c3422596ab 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -302,7 +302,7 @@ int smack_populate_secattr(struct smack_known *skp);
> /*
> * Shared data.
> */
> -extern int smack_enabled;
> +extern int smack_enabled __initdata;
> extern int smack_cipso_direct;
> extern int smack_cipso_mapped;
> extern struct smack_known *smack_net_ambient;
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 223a6da0e6dc..cacbe7518519 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -54,7 +54,7 @@
> static DEFINE_MUTEX(smack_ipv6_lock);
> static LIST_HEAD(smk_ipv6_port_list);
> struct kmem_cache *smack_rule_cache;
> -int smack_enabled;
> +int smack_enabled __initdata;
>
> #define A(s) {"smack"#s, sizeof("smack"#s) - 1, Opt_##s}
> static struct {
> --
> 2.20.1
>
Dear Maintainers
Would you please review the above patch if you are available?
It might not take long.
Thanks.
Austin Kim
^ permalink raw reply
* [PATCH] ima: check control characters in policy path
From: Tianxing Zhang @ 2021-07-07 11:45 UTC (permalink / raw)
To: zohar; +Cc: linux-integrity, linux-security-module, Tianxing Zhang
When a policy file path contains control characters like '\r' or '\b',
invalid error messages can be printed to overwrite system messages:
$ echo -e "/\rtest 12345678" > /sys/kernel/security/ima/policy
This patch rejects policy paths with control characters.
Signed-off-by: Tianxing Zhang <anakinzhang96@gmail.com>
---
security/integrity/ima/ima_fs.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 3d8e9d5db5aa..e6daa138de89 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -316,6 +316,7 @@ static ssize_t ima_write_policy(struct file *file, const char __user *buf,
{
char *data;
ssize_t result;
+ int i;
if (datalen >= PAGE_SIZE)
datalen = PAGE_SIZE - 1;
@@ -331,6 +332,14 @@ static ssize_t ima_write_policy(struct file *file, const char __user *buf,
goto out;
}
+ for (i = 0; data[i] != '\n' && data[i] != '\0'; i++) {
+ if (iscntrl(data[i])) {
+ pr_err_once("file path with no control characters required\n");
+ result = -EINVAL;
+ goto out_free;
+ }
+ }
+
result = mutex_lock_interruptible(&ima_write_mutex);
if (result < 0)
goto out_free;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Mimi Zohar @ 2021-07-07 12:39 UTC (permalink / raw)
To: Eric Snowberg, keyrings, linux-integrity, dhowells, dwmw2,
herbert, davem, jarkko, jmorris, serge
Cc: keescook, gregkh, torvalds, scott.branden, weiyongjun1, nayna,
ebiggers, ardb, nramas, lszubowi, linux-kernel, linux-crypto,
linux-security-module, James.Bottomley, pjones, glin, konrad.wilk
In-Reply-To: <20210707024403.1083977-1-eric.snowberg@oracle.com>
On Tue, 2021-07-06 at 22:43 -0400, Eric Snowberg wrote:
> This is a follow up to the "Add additional MOK vars" [1] series I
> previously sent. This series incorporates the feedback given
> both publicly on the mailing list and privately from Mimi. This
> series just focuses on getting end-user keys into the kernel trust
> boundary.
>
> Currently, pre-boot keys are not trusted within the Linux boundary [2].
> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
> keys are loaded into the platform keyring and can only be used for kexec.
> If an end-user wants to use their own key within the Linux trust
> boundary, they must either compile it into the kernel themselves or use
> the insert-sys-cert script. Both options present a problem. Many
> end-users do not want to compile their own kernels. With the
> insert-sys-cert option, there are missing upstream changes [3]. Also,
> with the insert-sys-cert option, the end-user must re-sign their kernel
> again with their own key, and then insert that key into the MOK db.
> Another problem with insert-sys-cert is that only a single key can be
> inserted into a compressed kernel.
>
> Having the ability to insert a key into the Linux trust boundary opens
> up various possibilities. The end-user can use a pre-built kernel and
> sign their own kernel modules. It also opens up the ability for an
> end-user to more easily use digital signature based IMA-appraisal. To
> get a key into the ima keyring, it must be signed by a key within the
> Linux trust boundary.
>
> Downstream Linux distros try to have a single signed kernel for each
> architecture. Each end-user may use this kernel in entirely different
> ways. Some downstream kernels have chosen to always trust platform keys
> within the Linux trust boundary for kernel module signing. These
> kernels have no way of using digital signature base IMA appraisal.
>
> This series adds a new MOK variable to shim. This variable allows the
> end-user to decide if they want to trust keys enrolled in the MOK within
> the Linux trust boundary. By default, nothing changes; MOK keys are
> not trusted within the Linux kernel. They are only trusted after the
> end-user makes the decision themselves. The end-user would set this
> through mokutil using a new --trust-mok option [4]. This would work
> similar to how the kernel uses MOK variable to enable/disable signature
> validation as well as use/ignore the db.
>
> When shim boots, it mirrors the new MokTML Boot Services variable to a new
> MokListTrustedRT Runtime Services variable and extends PCR14.
> MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
> preventing an end-user from setting it after booting and doing a kexec.
>
> When the kernel boots, if MokListTrustedRT is set and
> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
> secondary trusted keyring instead of the platform keyring. Mimi has
> suggested that only CA keys or keys that can be vouched for by other
> kernel keys be loaded. All other certs will load into the platform
> keyring instead.
Loading MOK CA keys onto the "secondary" keyring would need to be an
exception. Once CA keys are loaded onto the "secondary" keyring, any
certificates signed by those CA keys may be loaded normally, without
needing an exception, onto the "secondary" keyring. The kernel MAY
load those keys onto the "secondary" keyring, but really doesn't need
to be involved.
Loading ALL of the MOK db keys onto either the "secondary" or
"platform" keyrings makes the code a lot more complicated. Is it
really necessary?
thanks,
Mimi
>
> This is done by introducing a new .mok keyring. This keyring is only
> used during boot. After booting it is destroyed and not visible to the
> end-user after booting completes. This keyring contains a new keyring
> permission that only allows CA keys to be loaded. If the permission
> fails, the key is later loaded into the platform keyring. After keys
> are added into the .mok keyring, they are moved into the secondary
> trusted keyring.
>
> Secure Boot keys will never be trusted. They will always be loaded
> into the platform keyring. If an end-user wanted to trust one, they
> would need to enroll it into the MOK.
>
> I have included links to both the mokutil [3] and shim [4] changes I
> have made to support this new functionality.
>
> Thank you and looking forward to hearing your reviews.
>
> [1] https://lore.kernel.org/linux-integrity/20210517225714.498032-1-eric.snowberg@oracle.com/
> [2] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
> [3] https://lore.kernel.org/patchwork/cover/902768/
> [4] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars-v2
> [5] https://github.com/esnowberg/shim/tree/mokvars-v2
>
> Eric Snowberg (12):
> KEYS: Add KEY_ALLOC_BYPASS_RESTRICTION option to key_move
> KEYS: Allow unrestricted keys to be moved to the secondary keyring
> KEYS: CA link restriction
> integrity: add integrity_destroy_keyring
> integrity: Introduce mok keyring
> integrity: Trust mok keys if MokListTrustedRT found
> integrity: add add_to_mok_keyring
> integrity: restrict INTEGRITY_KEYRING_MOK to
> restrict_link_by_secondary_trusted_or_ca
> integrity: accessor function to get trust_moklist
> integrity: add new keyring handler
> integrity: move keys from the mok keyring into the secondary keyring
> integrity: Suppress error message for keys added to the mok keyring
>
> certs/system_keyring.c | 43 +++++++++
> crypto/asymmetric_keys/restrict.c | 60 +++++++++++++
> include/crypto/public_key.h | 5 ++
> include/keys/system_keyring.h | 21 +++++
> security/integrity/Makefile | 3 +-
> security/integrity/digsig.c | 26 +++++-
> security/integrity/integrity.h | 21 ++++-
> .../platform_certs/keyring_handler.c | 17 +++-
> .../platform_certs/keyring_handler.h | 5 ++
> security/integrity/platform_certs/load_uefi.c | 5 +-
> .../integrity/platform_certs/mok_keyring.c | 90 +++++++++++++++++++
> security/keys/keyring.c | 10 ++-
> 12 files changed, 294 insertions(+), 12 deletions(-)
> create mode 100644 security/integrity/platform_certs/mok_keyring.c
>
>
> base-commit: 13311e74253fe64329390df80bed3f07314ddd61
^ permalink raw reply
* Re: [PATCH] smack: mark 'smack_enabled' global variable as __initdata
From: Casey Schaufler @ 2021-07-07 14:27 UTC (permalink / raw)
To: Austin Kim, James Morris, Serge E. Hallyn
Cc: linux-security-module, Linux Kernel Mailing List, kernel-team,
Casey Schaufler
In-Reply-To: <CADLLry4_qB607aC2WdjvH6+QWijPNU4cQNhacr-mLOBN-heZAA@mail.gmail.com>
On 7/7/2021 3:14 AM, Austin Kim wrote:
> 2021년 6월 29일 (화) 오후 10:41, Austin Kim <austindh.kim@gmail.com>님이 작성:
>> From: Austin Kim <austin.kim@lge.com>
>>
>> Mark 'smack_enabled' as __initdata
>> since it is only used during initialization code.
>>
>> Signed-off-by: Austin Kim <austin.kim@lge.com>
I will be taking this patch for 5.15. You should see it in next
shortly after the 5.14 merge window closes.
>> ---
>> security/smack/smack.h | 2 +-
>> security/smack/smack_lsm.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/smack/smack.h b/security/smack/smack.h
>> index c3cfbdf4944a..99c3422596ab 100644
>> --- a/security/smack/smack.h
>> +++ b/security/smack/smack.h
>> @@ -302,7 +302,7 @@ int smack_populate_secattr(struct smack_known *skp);
>> /*
>> * Shared data.
>> */
>> -extern int smack_enabled;
>> +extern int smack_enabled __initdata;
>> extern int smack_cipso_direct;
>> extern int smack_cipso_mapped;
>> extern struct smack_known *smack_net_ambient;
>> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
>> index 223a6da0e6dc..cacbe7518519 100644
>> --- a/security/smack/smack_lsm.c
>> +++ b/security/smack/smack_lsm.c
>> @@ -54,7 +54,7 @@
>> static DEFINE_MUTEX(smack_ipv6_lock);
>> static LIST_HEAD(smk_ipv6_port_list);
>> struct kmem_cache *smack_rule_cache;
>> -int smack_enabled;
>> +int smack_enabled __initdata;
>>
>> #define A(s) {"smack"#s, sizeof("smack"#s) - 1, Opt_##s}
>> static struct {
>> --
>> 2.20.1
>>
> Dear Maintainers
>
> Would you please review the above patch if you are available?
> It might not take long.
>
> Thanks.
> Austin Kim
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Eric Snowberg @ 2021-07-07 16:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: keyrings, linux-integrity, Mimi Zohar, David Howells,
David Woodhouse, herbert, davem, jarkko, jmorris, serge, keescook,
gregkh, torvalds, scott.branden, weiyongjun1, nayna, ebiggers,
ardb, nramas, lszubowi, linux-kernel, linux-crypto,
linux-security-module, James.Bottomley, pjones, glin,
konrad.wilk@oracle.com
In-Reply-To: <YOVNrhxCJpfTbpVq@infradead.org>
> On Jul 7, 2021, at 12:46 AM, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jul 06, 2021 at 10:43:51PM -0400, Eric Snowberg wrote:
>> This is a follow up to the "Add additional MOK vars" [1] series I
>> previously sent. This series incorporates the feedback given
>> both publicly on the mailing list and privately from Mimi. This
>> series just focuses on getting end-user keys into the kernel trust
>> boundary.
>
> WTF is MOK?
MOK stands for Machine Owner Key. The MOK facility can be used to
import keys that you use to sign your own development kernel build,
so that it is able to boot with UEFI Secure Boot enabled. Many Linux
distributions have implemented UEFI Secure Boot using these keys
as well as the ones Secure Boot provides. It allows the end-user
a choice, instead of locking them into only being able to use keys
their hardware manufacture provided, or forcing them to enroll keys
through their BIOS.
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Eric Snowberg @ 2021-07-07 16:28 UTC (permalink / raw)
To: Mimi Zohar
Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
serge, keescook, gregkh, torvalds, scott.branden, weiyongjun1,
nayna, ebiggers, ardb, nramas, lszubowi, linux-kernel,
linux-crypto, linux-security-module, James.Bottomley, pjones,
glin, konrad.wilk@oracle.com
In-Reply-To: <42b787dd3a20fe37c4de60daf75db06e409cfb6d.camel@linux.ibm.com>
> On Jul 7, 2021, at 6:39 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Tue, 2021-07-06 at 22:43 -0400, Eric Snowberg wrote:
>> This is a follow up to the "Add additional MOK vars" [1] series I
>> previously sent. This series incorporates the feedback given
>> both publicly on the mailing list and privately from Mimi. This
>> series just focuses on getting end-user keys into the kernel trust
>> boundary.
>>
>> Currently, pre-boot keys are not trusted within the Linux boundary [2].
>> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
>> keys are loaded into the platform keyring and can only be used for kexec.
>> If an end-user wants to use their own key within the Linux trust
>> boundary, they must either compile it into the kernel themselves or use
>> the insert-sys-cert script. Both options present a problem. Many
>> end-users do not want to compile their own kernels. With the
>> insert-sys-cert option, there are missing upstream changes [3]. Also,
>> with the insert-sys-cert option, the end-user must re-sign their kernel
>> again with their own key, and then insert that key into the MOK db.
>> Another problem with insert-sys-cert is that only a single key can be
>> inserted into a compressed kernel.
>>
>> Having the ability to insert a key into the Linux trust boundary opens
>> up various possibilities. The end-user can use a pre-built kernel and
>> sign their own kernel modules. It also opens up the ability for an
>> end-user to more easily use digital signature based IMA-appraisal. To
>> get a key into the ima keyring, it must be signed by a key within the
>> Linux trust boundary.
>>
>> Downstream Linux distros try to have a single signed kernel for each
>> architecture. Each end-user may use this kernel in entirely different
>> ways. Some downstream kernels have chosen to always trust platform keys
>> within the Linux trust boundary for kernel module signing. These
>> kernels have no way of using digital signature base IMA appraisal.
>>
>> This series adds a new MOK variable to shim. This variable allows the
>> end-user to decide if they want to trust keys enrolled in the MOK within
>> the Linux trust boundary. By default, nothing changes; MOK keys are
>> not trusted within the Linux kernel. They are only trusted after the
>> end-user makes the decision themselves. The end-user would set this
>> through mokutil using a new --trust-mok option [4]. This would work
>> similar to how the kernel uses MOK variable to enable/disable signature
>> validation as well as use/ignore the db.
>>
>> When shim boots, it mirrors the new MokTML Boot Services variable to a new
>> MokListTrustedRT Runtime Services variable and extends PCR14.
>> MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
>> preventing an end-user from setting it after booting and doing a kexec.
>>
>> When the kernel boots, if MokListTrustedRT is set and
>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
>> secondary trusted keyring instead of the platform keyring. Mimi has
>> suggested that only CA keys or keys that can be vouched for by other
>> kernel keys be loaded. All other certs will load into the platform
>> keyring instead.
>
> Loading MOK CA keys onto the "secondary" keyring would need to be an
> exception. Once CA keys are loaded onto the "secondary" keyring, any
> certificates signed by those CA keys may be loaded normally, without
> needing an exception, onto the "secondary" keyring. The kernel MAY
> load those keys onto the "secondary" keyring, but really doesn't need
> to be involved.
>
> Loading ALL of the MOK db keys onto either the "secondary" or
> "platform" keyrings makes the code a lot more complicated. Is it
> really necessary?
Today all keys are loaded into the platform keyring. For kexec_file_load,
the platform and secondary keys are trusted the same. If this series were
not to load them all into either keyring, it would be a kexec_file_load
regression, since keys that previously loaded into the platform keyring
could be missing. The complexity arises from the CA key restriction.
If that requirement was removed, this series would be much smaller.
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Christoph Hellwig @ 2021-07-07 16:28 UTC (permalink / raw)
To: Eric Snowberg
Cc: Christoph Hellwig, keyrings, linux-integrity, Mimi Zohar,
David Howells, David Woodhouse, herbert, davem, jarkko, jmorris,
serge, keescook, gregkh, torvalds, scott.branden, weiyongjun1,
nayna, ebiggers, ardb, nramas, lszubowi, linux-kernel,
linux-crypto, linux-security-module, James.Bottomley, pjones,
glin, konrad.wilk@oracle.com
In-Reply-To: <E4A6A4E2-F9CB-4996-965A-772B3CA15555@oracle.com>
On Wed, Jul 07, 2021 at 10:23:04AM -0600, Eric Snowberg wrote:
>
> > On Jul 7, 2021, at 12:46 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Jul 06, 2021 at 10:43:51PM -0400, Eric Snowberg wrote:
> >> This is a follow up to the "Add additional MOK vars" [1] series I
> >> previously sent. This series incorporates the feedback given
> >> both publicly on the mailing list and privately from Mimi. This
> >> series just focuses on getting end-user keys into the kernel trust
> >> boundary.
> >
> > WTF is MOK?
>
> MOK stands for Machine Owner Key. The MOK facility can be used to
> import keys that you use to sign your own development kernel build,
> so that it is able to boot with UEFI Secure Boot enabled. Many Linux
> distributions have implemented UEFI Secure Boot using these keys
> as well as the ones Secure Boot provides. It allows the end-user
> a choice, instead of locking them into only being able to use keys
> their hardware manufacture provided, or forcing them to enroll keys
> through their BIOS.
Please spell this out in your cover letters and commit logs.
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Eric Snowberg @ 2021-07-07 16:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: keyrings, linux-integrity, Mimi Zohar, David Howells,
David Woodhouse, herbert, davem, jarkko, jmorris, serge, keescook,
gregkh, torvalds, scott.branden, weiyongjun1, nayna, ebiggers,
ardb, nramas, lszubowi, linux-kernel, linux-crypto,
linux-security-module, James.Bottomley, pjones, glin,
konrad.wilk@oracle.com
In-Reply-To: <YOXWOaPma2dMf6fk@infradead.org>
> On Jul 7, 2021, at 10:28 AM, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Jul 07, 2021 at 10:23:04AM -0600, Eric Snowberg wrote:
>>
>>> On Jul 7, 2021, at 12:46 AM, Christoph Hellwig <hch@infradead.org> wrote:
>>>
>>> On Tue, Jul 06, 2021 at 10:43:51PM -0400, Eric Snowberg wrote:
>>>> This is a follow up to the "Add additional MOK vars" [1] series I
>>>> previously sent. This series incorporates the feedback given
>>>> both publicly on the mailing list and privately from Mimi. This
>>>> series just focuses on getting end-user keys into the kernel trust
>>>> boundary.
>>>
>>> WTF is MOK?
>>
>> MOK stands for Machine Owner Key. The MOK facility can be used to
>> import keys that you use to sign your own development kernel build,
>> so that it is able to boot with UEFI Secure Boot enabled. Many Linux
>> distributions have implemented UEFI Secure Boot using these keys
>> as well as the ones Secure Boot provides. It allows the end-user
>> a choice, instead of locking them into only being able to use keys
>> their hardware manufacture provided, or forcing them to enroll keys
>> through their BIOS.
>
> Please spell this out in your cover letters and commit logs.
I will add it in the future, thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Mimi Zohar @ 2021-07-07 17:00 UTC (permalink / raw)
To: Eric Snowberg
Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
serge, keescook, gregkh, torvalds, scott.branden, weiyongjun1,
nayna, ebiggers, ardb, nramas, lszubowi, linux-kernel,
linux-crypto, linux-security-module, James.Bottomley, pjones,
glin, konrad.wilk@oracle.com
In-Reply-To: <5BFB3C52-36D4-47A5-B1B8-977717C555A0@oracle.com>
On Wed, 2021-07-07 at 10:28 -0600, Eric Snowberg wrote:
> > On Jul 7, 2021, at 6:39 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Tue, 2021-07-06 at 22:43 -0400, Eric Snowberg wrote:
> >> This is a follow up to the "Add additional MOK vars" [1] series I
> >> previously sent. This series incorporates the feedback given
> >> both publicly on the mailing list and privately from Mimi. This
> >> series just focuses on getting end-user keys into the kernel trust
> >> boundary.
> >>
> >> Currently, pre-boot keys are not trusted within the Linux boundary [2].
> >> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
> >> keys are loaded into the platform keyring and can only be used for kexec.
> >> If an end-user wants to use their own key within the Linux trust
> >> boundary, they must either compile it into the kernel themselves or use
> >> the insert-sys-cert script. Both options present a problem. Many
> >> end-users do not want to compile their own kernels. With the
> >> insert-sys-cert option, there are missing upstream changes [3]. Also,
> >> with the insert-sys-cert option, the end-user must re-sign their kernel
> >> again with their own key, and then insert that key into the MOK db.
> >> Another problem with insert-sys-cert is that only a single key can be
> >> inserted into a compressed kernel.
> >>
> >> Having the ability to insert a key into the Linux trust boundary opens
> >> up various possibilities. The end-user can use a pre-built kernel and
> >> sign their own kernel modules. It also opens up the ability for an
> >> end-user to more easily use digital signature based IMA-appraisal. To
> >> get a key into the ima keyring, it must be signed by a key within the
> >> Linux trust boundary.
> >>
> >> Downstream Linux distros try to have a single signed kernel for each
> >> architecture. Each end-user may use this kernel in entirely different
> >> ways. Some downstream kernels have chosen to always trust platform keys
> >> within the Linux trust boundary for kernel module signing. These
> >> kernels have no way of using digital signature base IMA appraisal.
> >>
> >> This series adds a new MOK variable to shim. This variable allows the
> >> end-user to decide if they want to trust keys enrolled in the MOK within
> >> the Linux trust boundary. By default, nothing changes; MOK keys are
> >> not trusted within the Linux kernel. They are only trusted after the
> >> end-user makes the decision themselves. The end-user would set this
> >> through mokutil using a new --trust-mok option [4]. This would work
> >> similar to how the kernel uses MOK variable to enable/disable signature
> >> validation as well as use/ignore the db.
> >>
> >> When shim boots, it mirrors the new MokTML Boot Services variable to a new
> >> MokListTrustedRT Runtime Services variable and extends PCR14.
> >> MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
> >> preventing an end-user from setting it after booting and doing a kexec.
> >>
> >> When the kernel boots, if MokListTrustedRT is set and
> >> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
> >> secondary trusted keyring instead of the platform keyring. Mimi has
> >> suggested that only CA keys or keys that can be vouched for by other
> >> kernel keys be loaded. All other certs will load into the platform
> >> keyring instead.
> >
> > Loading MOK CA keys onto the "secondary" keyring would need to be an
> > exception. Once CA keys are loaded onto the "secondary" keyring, any
> > certificates signed by those CA keys may be loaded normally, without
> > needing an exception, onto the "secondary" keyring. The kernel MAY
> > load those keys onto the "secondary" keyring, but really doesn't need
> > to be involved.
> >
> > Loading ALL of the MOK db keys onto either the "secondary" or
> > "platform" keyrings makes the code a lot more complicated. Is it
> > really necessary?
>
> Today all keys are loaded into the platform keyring. For kexec_file_load,
> the platform and secondary keys are trusted the same. If this series were
> not to load them all into either keyring, it would be a kexec_file_load
> regression, since keys that previously loaded into the platform keyring
> could be missing. The complexity arises from the CA key restriction.
> If that requirement was removed, this series would be much smaller.
To prevent the regression, allow the the existing firmware/UEFI keys to
continue to be loaded on the platform keyring, as it is currently being
done. The new code would load just the MOK db CA keys onto the
secondary keyring, based on the new UEFI variable. This is the only
code that would require a
"restrict_link_by_builtin_and_secondary_trusted" exemption. The code
duplication would be minimal in comparison to the complexity being
introduced.
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH RFC 05/12] integrity: Introduce mok keyring
From: Linus Torvalds @ 2021-07-07 19:31 UTC (permalink / raw)
To: Eric Snowberg
Cc: keyrings, linux-integrity, Mimi Zohar, David Howells,
David Woodhouse, Herbert Xu, David Miller, Jarkko Sakkinen,
James Morris James Morris, Serge E. Hallyn, Kees Cook,
Greg Kroah-Hartman, scott.branden, Wei Yongjun, Nayna Jain,
Eric Biggers, Ard Biesheuvel, nramas, Lenny Szubowicz,
Linux Kernel Mailing List, Linux Crypto Mailing List, LSM List,
James Bottomley, Peter Jones, Gary Lin, Konrad Rzeszutek Wilk
In-Reply-To: <20210707024403.1083977-6-eric.snowberg@oracle.com>
On Tue, Jul 6, 2021 at 7:45 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>
> Introduce a new keyring called mok. This keyring will be used during
> boot. Afterwards it will be destroyed.
Already discussed elsewhere, but yeah, when using TLA's, unless they
are universally understood (like "CPU" or "TLB" or whatever), please
spell them out somewhere for people who don't have the background.
I saw that you said elsewhere that MOK is "Machine Owner Key", but
please let's just have that in the sources and commit messages at
least for the original new code cases.
Maybe it becomes obvious over time as there is more history to the
code, but when you literally introduce a new concept, please spell it
out.
Linus
^ permalink raw reply
* Re: [PATCH RFC 05/12] integrity: Introduce mok keyring
From: Jarkko Sakkinen @ 2021-07-07 21:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Snowberg, keyrings, linux-integrity, Mimi Zohar,
David Howells, David Woodhouse, Herbert Xu, David Miller,
James Morris James Morris, Serge E. Hallyn, Kees Cook,
Greg Kroah-Hartman, scott.branden, Wei Yongjun, Nayna Jain,
Eric Biggers, Ard Biesheuvel, nramas, Lenny Szubowicz,
Linux Kernel Mailing List, Linux Crypto Mailing List, LSM List,
James Bottomley, Peter Jones, Gary Lin, Konrad Rzeszutek Wilk
In-Reply-To: <CAHk-=wgEncBgRdv0FZjmZGQP5tzcdYA0XJrxmBEOevi06dimtw@mail.gmail.com>
On Wed, Jul 07, 2021 at 12:31:23PM -0700, Linus Torvalds wrote:
> On Tue, Jul 6, 2021 at 7:45 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >
> > Introduce a new keyring called mok. This keyring will be used during
> > boot. Afterwards it will be destroyed.
>
> Already discussed elsewhere, but yeah, when using TLA's, unless they
> are universally understood (like "CPU" or "TLB" or whatever), please
> spell them out somewhere for people who don't have the background.
>
> I saw that you said elsewhere that MOK is "Machine Owner Key", but
> please let's just have that in the sources and commit messages at
> least for the original new code cases.
>
> Maybe it becomes obvious over time as there is more history to the
> code, but when you literally introduce a new concept, please spell it
> out.
>
> Linus
>
I'd suggest for the short summary:
"integrity: Introduce a Linux keyring for the Machine Owner Key (MOK)"
Given that "keyring" is such a saturated and ambiguous word, and this not a
subsystem patch for keyring itself, it should be explicit what is meant by
a keyring.
/Jarkko
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Eric Snowberg @ 2021-07-07 22:10 UTC (permalink / raw)
To: Mimi Zohar
Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
Serge E . Hallyn, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk@oracle.com
In-Reply-To: <886f30dcf7b3d48644289acc3601c2f0207b19b6.camel@linux.ibm.com>
> On Jul 7, 2021, at 11:00 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Wed, 2021-07-07 at 10:28 -0600, Eric Snowberg wrote:
>>> On Jul 7, 2021, at 6:39 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>
>>> On Tue, 2021-07-06 at 22:43 -0400, Eric Snowberg wrote:
>>>> This is a follow up to the "Add additional MOK vars" [1] series I
>>>> previously sent. This series incorporates the feedback given
>>>> both publicly on the mailing list and privately from Mimi. This
>>>> series just focuses on getting end-user keys into the kernel trust
>>>> boundary.
>>>>
>>>> Currently, pre-boot keys are not trusted within the Linux boundary [2].
>>>> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
>>>> keys are loaded into the platform keyring and can only be used for kexec.
>>>> If an end-user wants to use their own key within the Linux trust
>>>> boundary, they must either compile it into the kernel themselves or use
>>>> the insert-sys-cert script. Both options present a problem. Many
>>>> end-users do not want to compile their own kernels. With the
>>>> insert-sys-cert option, there are missing upstream changes [3]. Also,
>>>> with the insert-sys-cert option, the end-user must re-sign their kernel
>>>> again with their own key, and then insert that key into the MOK db.
>>>> Another problem with insert-sys-cert is that only a single key can be
>>>> inserted into a compressed kernel.
>>>>
>>>> Having the ability to insert a key into the Linux trust boundary opens
>>>> up various possibilities. The end-user can use a pre-built kernel and
>>>> sign their own kernel modules. It also opens up the ability for an
>>>> end-user to more easily use digital signature based IMA-appraisal. To
>>>> get a key into the ima keyring, it must be signed by a key within the
>>>> Linux trust boundary.
>>>>
>>>> Downstream Linux distros try to have a single signed kernel for each
>>>> architecture. Each end-user may use this kernel in entirely different
>>>> ways. Some downstream kernels have chosen to always trust platform keys
>>>> within the Linux trust boundary for kernel module signing. These
>>>> kernels have no way of using digital signature base IMA appraisal.
>>>>
>>>> This series adds a new MOK variable to shim. This variable allows the
>>>> end-user to decide if they want to trust keys enrolled in the MOK within
>>>> the Linux trust boundary. By default, nothing changes; MOK keys are
>>>> not trusted within the Linux kernel. They are only trusted after the
>>>> end-user makes the decision themselves. The end-user would set this
>>>> through mokutil using a new --trust-mok option [4]. This would work
>>>> similar to how the kernel uses MOK variable to enable/disable signature
>>>> validation as well as use/ignore the db.
>>>>
>>>> When shim boots, it mirrors the new MokTML Boot Services variable to a new
>>>> MokListTrustedRT Runtime Services variable and extends PCR14.
>>>> MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
>>>> preventing an end-user from setting it after booting and doing a kexec.
>>>>
>>>> When the kernel boots, if MokListTrustedRT is set and
>>>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
>>>> secondary trusted keyring instead of the platform keyring. Mimi has
>>>> suggested that only CA keys or keys that can be vouched for by other
>>>> kernel keys be loaded. All other certs will load into the platform
>>>> keyring instead.
>>>
>>> Loading MOK CA keys onto the "secondary" keyring would need to be an
>>> exception. Once CA keys are loaded onto the "secondary" keyring, any
>>> certificates signed by those CA keys may be loaded normally, without
>>> needing an exception, onto the "secondary" keyring. The kernel MAY
>>> load those keys onto the "secondary" keyring, but really doesn't need
>>> to be involved.
>>>
>>> Loading ALL of the MOK db keys onto either the "secondary" or
>>> "platform" keyrings makes the code a lot more complicated. Is it
>>> really necessary?
>>
>> Today all keys are loaded into the platform keyring. For kexec_file_load,
>> the platform and secondary keys are trusted the same. If this series were
>> not to load them all into either keyring, it would be a kexec_file_load
>> regression, since keys that previously loaded into the platform keyring
>> could be missing. The complexity arises from the CA key restriction.
>> If that requirement was removed, this series would be much smaller.
>
> To prevent the regression, allow the the existing firmware/UEFI keys to
> continue to be loaded on the platform keyring, as it is currently being
> done. The new code would load just the MOK db CA keys onto the
> secondary keyring, based on the new UEFI variable. This is the only
> code that would require a
> "restrict_link_by_builtin_and_secondary_trusted" exemption. The code
> duplication would be minimal in comparison to the complexity being
> introduced.
This series was written with the following three requirements in mind:
1. Only CA keys that were originally bound for the platform keyring
can enter the secondary keyring.
2. No key in the UEFI Secure Boot DB, CA or not, may enter the
secondary keyring, only MOKList keys may be trusted.
3. A new MOK variable is added to signify the user wants to trust
MOKList keys.
Given these requirements, I started down the path I think you are
suggesting. However I found it to be more complex. If we load all
keys into the platform keyring first and later try to load only CA keys,
we don’t have a way of knowing where the platform key came from.
Platform keys can originate from the UEFI Secure Boot DB or the MOKList.
This would violate the second requirement. This caused me to need to
create a new keyring handler. [PATCH RFC 10/12] integrity: add new
keyring handler.
To satisfy the first requirement a new restriction is required. This
is contained in [PATCH RFC 03/12] KEYS: CA link restriction.
To satisfy the third requirement, we must read the new MOK var. This
is contained in [PATCH RFC 06/12] integrity: Trust mok keys if
MokListTrustedRT found.
The patches above make up a majority of the new code.
The remaining code of creating a new .mok keyring was done with code
reuse in mind. Many of the required functions necessary to add this
capability is already contained in integrity_ functions. If the
operation was done directly on the secondary keyring, similar code
would need to be added to certs/system_keyring.c. Just like how the
platform keyring is created within integrity code, the mok keyring
is created in the same fashion. When the platform keyring has
completed initialization and loaded all its keys, the keyring is set
into system_keyring code using set_platform_trusted_keys. Instead of
setting the mok keyring, I’m moving the keys directly into the secondary
keyring, while bypassing the current restriction placed on this keyring.
Basically I'm trying to follow the same design pattern.
If requirements #1, #2 or both (#1 and #2) could be dropped, most of
this series would not be necessary.
^ permalink raw reply
* Re: [PATCH RFC 05/12] integrity: Introduce mok keyring
From: Eric Snowberg @ 2021-07-07 22:32 UTC (permalink / raw)
To: Jarkko Sakkinen, Linus Torvalds
Cc: keyrings, linux-integrity, Mimi Zohar, David Howells,
David Woodhouse, Herbert Xu, David Miller,
James Morris James Morris, Serge E. Hallyn, Kees Cook,
Greg Kroah-Hartman, scott.branden, Wei Yongjun, Nayna Jain,
Eric Biggers, Ard Biesheuvel, Lakshmi Ramasubramanian,
Lenny Szubowicz, Linux Kernel Mailing List,
Linux Crypto Mailing List, LSM List, James Bottomley, Peter Jones,
Gary Lin, konrad.wilk@oracle.com
In-Reply-To: <20210707212611.pdkmkxhqomkf4ngg@kernel.org>
> On Jul 7, 2021, at 3:26 PM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Wed, Jul 07, 2021 at 12:31:23PM -0700, Linus Torvalds wrote:
>> On Tue, Jul 6, 2021 at 7:45 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>
>>> Introduce a new keyring called mok. This keyring will be used during
>>> boot. Afterwards it will be destroyed.
>>
>> Already discussed elsewhere, but yeah, when using TLA's, unless they
>> are universally understood (like "CPU" or "TLB" or whatever), please
>> spell them out somewhere for people who don't have the background.
>>
>> I saw that you said elsewhere that MOK is "Machine Owner Key", but
>> please let's just have that in the sources and commit messages at
>> least for the original new code cases.
>>
>> Maybe it becomes obvious over time as there is more history to the
>> code, but when you literally introduce a new concept, please spell it
>> out.
>>
>> Linus
>>
> I'd suggest for the short summary:
>
> "integrity: Introduce a Linux keyring for the Machine Owner Key (MOK)"
>
> Given that "keyring" is such a saturated and ambiguous word, and this not a
> subsystem patch for keyring itself, it should be explicit what is meant by
> a keyring.
If we can go in this direction, I will update the heading as Jarkko has
suggested in a follow on series. I will also include a better summary in
this patch, along with a MOK explanation at the beginning. Thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Mimi Zohar @ 2021-07-08 13:56 UTC (permalink / raw)
To: Eric Snowberg
Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
Serge E . Hallyn, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk@oracle.com
In-Reply-To: <D34A6328-91CA-4E1E-845C-FAC9B424819B@oracle.com>
On Wed, 2021-07-07 at 16:10 -0600, Eric Snowberg wrote:
> > On Jul 7, 2021, at 11:00 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Wed, 2021-07-07 at 10:28 -0600, Eric Snowberg wrote:
> >>> On Jul 7, 2021, at 6:39 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>
> >>> On Tue, 2021-07-06 at 22:43 -0400, Eric Snowberg wrote:
> >>>> This is a follow up to the "Add additional MOK vars" [1] series I
> >>>> previously sent. This series incorporates the feedback given
> >>>> both publicly on the mailing list and privately from Mimi. This
> >>>> series just focuses on getting end-user keys into the kernel trust
> >>>> boundary.
> >>>>
> >>>> Currently, pre-boot keys are not trusted within the Linux boundary [2].
> >>>> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
> >>>> keys are loaded into the platform keyring and can only be used for kexec.
> >>>> If an end-user wants to use their own key within the Linux trust
> >>>> boundary, they must either compile it into the kernel themselves or use
> >>>> the insert-sys-cert script. Both options present a problem. Many
> >>>> end-users do not want to compile their own kernels. With the
> >>>> insert-sys-cert option, there are missing upstream changes [3]. Also,
> >>>> with the insert-sys-cert option, the end-user must re-sign their kernel
> >>>> again with their own key, and then insert that key into the MOK db.
> >>>> Another problem with insert-sys-cert is that only a single key can be
> >>>> inserted into a compressed kernel.
> >>>>
> >>>> Having the ability to insert a key into the Linux trust boundary opens
> >>>> up various possibilities. The end-user can use a pre-built kernel and
> >>>> sign their own kernel modules. It also opens up the ability for an
> >>>> end-user to more easily use digital signature based IMA-appraisal. To
> >>>> get a key into the ima keyring, it must be signed by a key within the
> >>>> Linux trust boundary.
> >>>>
> >>>> Downstream Linux distros try to have a single signed kernel for each
> >>>> architecture. Each end-user may use this kernel in entirely different
> >>>> ways. Some downstream kernels have chosen to always trust platform keys
> >>>> within the Linux trust boundary for kernel module signing. These
> >>>> kernels have no way of using digital signature base IMA appraisal.
> >>>>
> >>>> This series adds a new MOK variable to shim. This variable allows the
> >>>> end-user to decide if they want to trust keys enrolled in the MOK within
> >>>> the Linux trust boundary. By default, nothing changes; MOK keys are
> >>>> not trusted within the Linux kernel. They are only trusted after the
> >>>> end-user makes the decision themselves. The end-user would set this
> >>>> through mokutil using a new --trust-mok option [4]. This would work
> >>>> similar to how the kernel uses MOK variable to enable/disable signature
> >>>> validation as well as use/ignore the db.
> >>>>
> >>>> When shim boots, it mirrors the new MokTML Boot Services variable to a new
> >>>> MokListTrustedRT Runtime Services variable and extends PCR14.
> >>>> MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
> >>>> preventing an end-user from setting it after booting and doing a kexec.
> >>>>
> >>>> When the kernel boots, if MokListTrustedRT is set and
> >>>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
> >>>> secondary trusted keyring instead of the platform keyring. Mimi has
> >>>> suggested that only CA keys or keys that can be vouched for by other
> >>>> kernel keys be loaded. All other certs will load into the platform
> >>>> keyring instead.
> >>>
> >>> Loading MOK CA keys onto the "secondary" keyring would need to be an
> >>> exception. Once CA keys are loaded onto the "secondary" keyring, any
> >>> certificates signed by those CA keys may be loaded normally, without
> >>> needing an exception, onto the "secondary" keyring. The kernel MAY
> >>> load those keys onto the "secondary" keyring, but really doesn't need
> >>> to be involved.
> >>>
> >>> Loading ALL of the MOK db keys onto either the "secondary" or
> >>> "platform" keyrings makes the code a lot more complicated. Is it
> >>> really necessary?
> >>
> >> Today all keys are loaded into the platform keyring. For kexec_file_load,
> >> the platform and secondary keys are trusted the same. If this series were
> >> not to load them all into either keyring, it would be a kexec_file_load
> >> regression, since keys that previously loaded into the platform keyring
> >> could be missing. The complexity arises from the CA key restriction.
> >> If that requirement was removed, this series would be much smaller.
> >
> > To prevent the regression, allow the the existing firmware/UEFI keys to
> > continue to be loaded on the platform keyring, as it is currently being
> > done. The new code would load just the MOK db CA keys onto the
> > secondary keyring, based on the new UEFI variable. This is the only
> > code that would require a
> > "restrict_link_by_builtin_and_secondary_trusted" exemption. The code
> > duplication would be minimal in comparison to the complexity being
> > introduced.
>
> This series was written with the following three requirements in mind:
>
> 1. Only CA keys that were originally bound for the platform keyring
> can enter the secondary keyring.
>
> 2. No key in the UEFI Secure Boot DB, CA or not, may enter the
> secondary keyring, only MOKList keys may be trusted.
>
> 3. A new MOK variable is added to signify the user wants to trust
> MOKList keys.
Sounds good!
>
> Given these requirements, I started down the path I think you are
> suggesting. However I found it to be more complex. If we load all
> keys into the platform keyring first and later try to load only CA keys,
> we don’t have a way of knowing where the platform key came from.
> Platform keys can originate from the UEFI Secure Boot DB or the MOKList.
> This would violate the second requirement. This caused me to need to
> create a new keyring handler. [PATCH RFC 10/12] integrity: add new
> keyring handler.
To prevent the regression you mentioned, I was suggesting reading the
MOK DB twice. One time loading all the keys onto the platform keyring.
The other time loading only the CA keys onto the secondary keyring.
>
> To satisfy the first requirement a new restriction is required. This
> is contained in [PATCH RFC 03/12] KEYS: CA link restriction.
>
> To satisfy the third requirement, we must read the new MOK var. This
> is contained in [PATCH RFC 06/12] integrity: Trust mok keys if
> MokListTrustedRT found.
>
> The patches above make up a majority of the new code.
>
> The remaining code of creating a new .mok keyring was done with code
> reuse in mind. Many of the required functions necessary to add this
> capability is already contained in integrity_ functions. If the
> operation was done directly on the secondary keyring, similar code
> would need to be added to certs/system_keyring.c. Just like how the
> platform keyring is created within integrity code, the mok keyring
> is created in the same fashion. When the platform keyring has
> completed initialization and loaded all its keys, the keyring is set
> into system_keyring code using set_platform_trusted_keys. Instead of
> setting the mok keyring, I’m moving the keys directly into the secondary
> keyring, while bypassing the current restriction placed on this keyring.
> Basically I'm trying to follow the same design pattern.
>
> If requirements #1, #2 or both (#1 and #2) could be dropped, most of
> this series would not be necessary.
But without these requirements, the source of trust is unclear.
Is there a reason why the MOK keyring is temporary? Asumming a
function similar to "restrict_link_by_builtin_and_secondary_trusted" is
defined to include the MOK keyring, the CA keys in the MOK db would be
loaded onto the MOK keyring, the other keys that meet the secondary
keyring restriction would be loaded directly onto the secondary
keyring[1], and as you currently have, the remaining keys onto the
platform keyring.
This eliminates the exemption needed for loading keys onto the
secondary keyring. The MOK keyring, containing just CA keys, becomes a
new trust source.
thanks,
Mimi
[1] Refer to the comment in
restrict_link_by_builtin_and_secondary_trusted() on linking the builtin
keyring to the secondary keyring.
^ permalink raw reply
* [RFC PATCH v2 0/1] Relax restrictions on user.* xattr
From: Vivek Goyal @ 2021-07-08 17:57 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel, viro
Cc: virtio-fs, dwalsh, dgilbert, vgoyal, christian.brauner,
casey.schaufler, linux-security-module, selinux, tytso, miklos,
gscrivan, jack
Hi,
This is V2 of the patch. Posted V1 here.
https://lore.kernel.org/linux-fsdevel/20210625191229.1752531-1-vgoyal@redhat.com/
Right now we don't allow setting user.* xattrs on symlinks and special
files at all. Initially I thought that real reason behind this
restriction is quota limitations but from last conversation it seemed
that real reason is that permission bits on symlink and special files
are special and different from regular files and directories, hence
this restriction is in place.
Given it probably is not a quota issue (I tested with xfs user quota
enabled and quota restrictions kicked in on symlink), I dropped the
idea of allowing user.* xattr if process has CAP_SYS_RESOURCE.
Instead this version of patch allows reading/writing user.* xattr
on symlink and special files if caller is owner or priviliged (has
CAP_FOWNER) w.r.t inode.
We need this for virtiofs daemon. I also found one more user. Giuseppe,
seems to set user.* xattr attrs on unpriviliged fuse-overlay as well
and he ran into similar issue. So fuse-overlay should benefit from
this change as well.
Who wants to set user.* xattr on symlink/special files
-----------------------------------------------------
In virtiofs, actual file server is virtiosd daemon running on host.
There we have a mode where xattrs can be remapped to something else.
For example security.selinux can be remapped to
user.virtiofsd.securit.selinux on the host.
This remapping is useful when SELinux is enabled in guest and virtiofs
as being used as rootfs. Guest and host SELinux policy might not match
and host policy might deny security.selinux xattr setting by guest
onto host. Or host might have SELinux disabled and in that case to
be able to set security.selinux xattr, virtiofsd will need to have
CAP_SYS_ADMIN (which we are trying to avoid). Being able to remap
guest security.selinux (or other xattrs) on host to something else
is also better from security point of view.
But when we try this, we noticed that SELinux relabeling in guest
is failing on some symlinks. When I debugged a little more, I
came to know that "user.*" xattrs are not allowed on symlinks
or special files.
So if we allow owner (or CAP_FOWNER) to set user.* xattr, it will
allow virtiofs to arbitrarily remap guests's xattrs to something
else on host and that solves this SELinux issue nicely and provides
two SELinux policies (host and guest) to co-exist nicely without
interfering with each other.
Thanks
Vivek
Vivek Goyal (1):
xattr: Allow user.* xattr on symlink and special files
fs/xattr.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--
2.25.4
^ permalink raw reply
* [PATCH v2 1/1] xattr: Allow user.* xattr on symlink and special files
From: Vivek Goyal @ 2021-07-08 17:57 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel, viro
Cc: virtio-fs, dwalsh, dgilbert, vgoyal, christian.brauner,
casey.schaufler, linux-security-module, selinux, tytso, miklos,
gscrivan, jack
In-Reply-To: <20210708175738.360757-1-vgoyal@redhat.com>
Currently user.* xattr are not allowed on symlink and special files.
man xattr and recent discussion suggested that primary reason for this
restriction is how file permissions for symlinks and special files
are little different from regular files and directories.
For symlinks, they are world readable/writable and if user xattr were
to be permitted, it will allow unpriviliged users to dump a huge amount
of user.* xattrs on symlinks without any control.
For special files, permissions typically control capability to read/write
from devices (and not necessarily from filesystem). So if a user can
write to device (/dev/null), does not necessarily mean it should be allowed
to write large number of user.* xattrs on the filesystem device node is
residing in.
This patch proposes to relax the restrictions a bit and allow file owner
or priviliged user (CAP_FOWNER), to be able to read/write user.* xattrs
on symlink and special files.
virtiofs daemon has a need to store user.* xatrrs on all the files
(including symlinks and special files), and currently that fails. This
patch should help.
Link: https://lore.kernel.org/linux-fsdevel/20210625191229.1752531-1-vgoyal@redhat.com/
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
fs/xattr.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index 5c8c5175b385..2f1855c8b620 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -120,12 +120,14 @@ xattr_permission(struct user_namespace *mnt_userns, struct inode *inode,
}
/*
- * In the user.* namespace, only regular files and directories can have
- * extended attributes. For sticky directories, only the owner and
- * privileged users can write attributes.
+ * In the user.* namespace, for symlinks and special files, only
+ * the owner and priviliged users can read/write attributes.
+ * For sticky directories, only the owner and privileged users can
+ * write attributes.
*/
if (!strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN)) {
- if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode))
+ if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode) &&
+ !inode_owner_or_capable(mnt_userns, inode))
return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
if (S_ISDIR(inode->i_mode) && (inode->i_mode & S_ISVTX) &&
(mask & MAY_WRITE) &&
--
2.25.4
^ permalink raw reply related
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Eric Snowberg @ 2021-07-08 17:59 UTC (permalink / raw)
To: Mimi Zohar
Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
Serge E . Hallyn, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk@oracle.com
In-Reply-To: <c0cf7f883a9252c17427f1f992e4973e78481304.camel@linux.ibm.com>
> On Jul 8, 2021, at 7:56 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Wed, 2021-07-07 at 16:10 -0600, Eric Snowberg wrote:
>>> On Jul 7, 2021, at 11:00 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>
>>> On Wed, 2021-07-07 at 10:28 -0600, Eric Snowberg wrote:
>>>>> On Jul 7, 2021, at 6:39 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>
>>>>> On Tue, 2021-07-06 at 22:43 -0400, Eric Snowberg wrote:
>>>>>> This is a follow up to the "Add additional MOK vars" [1] series I
>>>>>> previously sent. This series incorporates the feedback given
>>>>>> both publicly on the mailing list and privately from Mimi. This
>>>>>> series just focuses on getting end-user keys into the kernel trust
>>>>>> boundary.
>>>>>>
>>>>>> Currently, pre-boot keys are not trusted within the Linux boundary [2].
>>>>>> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
>>>>>> keys are loaded into the platform keyring and can only be used for kexec.
>>>>>> If an end-user wants to use their own key within the Linux trust
>>>>>> boundary, they must either compile it into the kernel themselves or use
>>>>>> the insert-sys-cert script. Both options present a problem. Many
>>>>>> end-users do not want to compile their own kernels. With the
>>>>>> insert-sys-cert option, there are missing upstream changes [3]. Also,
>>>>>> with the insert-sys-cert option, the end-user must re-sign their kernel
>>>>>> again with their own key, and then insert that key into the MOK db.
>>>>>> Another problem with insert-sys-cert is that only a single key can be
>>>>>> inserted into a compressed kernel.
>>>>>>
>>>>>> Having the ability to insert a key into the Linux trust boundary opens
>>>>>> up various possibilities. The end-user can use a pre-built kernel and
>>>>>> sign their own kernel modules. It also opens up the ability for an
>>>>>> end-user to more easily use digital signature based IMA-appraisal. To
>>>>>> get a key into the ima keyring, it must be signed by a key within the
>>>>>> Linux trust boundary.
>>>>>>
>>>>>> Downstream Linux distros try to have a single signed kernel for each
>>>>>> architecture. Each end-user may use this kernel in entirely different
>>>>>> ways. Some downstream kernels have chosen to always trust platform keys
>>>>>> within the Linux trust boundary for kernel module signing. These
>>>>>> kernels have no way of using digital signature base IMA appraisal.
>>>>>>
>>>>>> This series adds a new MOK variable to shim. This variable allows the
>>>>>> end-user to decide if they want to trust keys enrolled in the MOK within
>>>>>> the Linux trust boundary. By default, nothing changes; MOK keys are
>>>>>> not trusted within the Linux kernel. They are only trusted after the
>>>>>> end-user makes the decision themselves. The end-user would set this
>>>>>> through mokutil using a new --trust-mok option [4]. This would work
>>>>>> similar to how the kernel uses MOK variable to enable/disable signature
>>>>>> validation as well as use/ignore the db.
>>>>>>
>>>>>> When shim boots, it mirrors the new MokTML Boot Services variable to a new
>>>>>> MokListTrustedRT Runtime Services variable and extends PCR14.
>>>>>> MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
>>>>>> preventing an end-user from setting it after booting and doing a kexec.
>>>>>>
>>>>>> When the kernel boots, if MokListTrustedRT is set and
>>>>>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
>>>>>> secondary trusted keyring instead of the platform keyring. Mimi has
>>>>>> suggested that only CA keys or keys that can be vouched for by other
>>>>>> kernel keys be loaded. All other certs will load into the platform
>>>>>> keyring instead.
>>>>>
>>>>> Loading MOK CA keys onto the "secondary" keyring would need to be an
>>>>> exception. Once CA keys are loaded onto the "secondary" keyring, any
>>>>> certificates signed by those CA keys may be loaded normally, without
>>>>> needing an exception, onto the "secondary" keyring. The kernel MAY
>>>>> load those keys onto the "secondary" keyring, but really doesn't need
>>>>> to be involved.
>>>>>
>>>>> Loading ALL of the MOK db keys onto either the "secondary" or
>>>>> "platform" keyrings makes the code a lot more complicated. Is it
>>>>> really necessary?
>>>>
>>>> Today all keys are loaded into the platform keyring. For kexec_file_load,
>>>> the platform and secondary keys are trusted the same. If this series were
>>>> not to load them all into either keyring, it would be a kexec_file_load
>>>> regression, since keys that previously loaded into the platform keyring
>>>> could be missing. The complexity arises from the CA key restriction.
>>>> If that requirement was removed, this series would be much smaller.
>>>
>>> To prevent the regression, allow the the existing firmware/UEFI keys to
>>> continue to be loaded on the platform keyring, as it is currently being
>>> done. The new code would load just the MOK db CA keys onto the
>>> secondary keyring, based on the new UEFI variable. This is the only
>>> code that would require a
>>> "restrict_link_by_builtin_and_secondary_trusted" exemption. The code
>>> duplication would be minimal in comparison to the complexity being
>>> introduced.
>>
>> This series was written with the following three requirements in mind:
>>
>> 1. Only CA keys that were originally bound for the platform keyring
>> can enter the secondary keyring.
>>
>> 2. No key in the UEFI Secure Boot DB, CA or not, may enter the
>> secondary keyring, only MOKList keys may be trusted.
>>
>> 3. A new MOK variable is added to signify the user wants to trust
>> MOKList keys.
>
> Sounds good!
>
>>
>> Given these requirements, I started down the path I think you are
>> suggesting. However I found it to be more complex. If we load all
>> keys into the platform keyring first and later try to load only CA keys,
>> we don’t have a way of knowing where the platform key came from.
>> Platform keys can originate from the UEFI Secure Boot DB or the MOKList.
>> This would violate the second requirement. This caused me to need to
>> create a new keyring handler. [PATCH RFC 10/12] integrity: add new
>> keyring handler.
>
> To prevent the regression you mentioned, I was suggesting reading the
> MOK DB twice. One time loading all the keys onto the platform keyring.
> The other time loading only the CA keys onto the secondary keyring.
>
>>
>> To satisfy the first requirement a new restriction is required. This
>> is contained in [PATCH RFC 03/12] KEYS: CA link restriction.
>>
>> To satisfy the third requirement, we must read the new MOK var. This
>> is contained in [PATCH RFC 06/12] integrity: Trust mok keys if
>> MokListTrustedRT found.
>>
>> The patches above make up a majority of the new code.
>>
>> The remaining code of creating a new .mok keyring was done with code
>> reuse in mind. Many of the required functions necessary to add this
>> capability is already contained in integrity_ functions. If the
>> operation was done directly on the secondary keyring, similar code
>> would need to be added to certs/system_keyring.c. Just like how the
>> platform keyring is created within integrity code, the mok keyring
>> is created in the same fashion. When the platform keyring has
>> completed initialization and loaded all its keys, the keyring is set
>> into system_keyring code using set_platform_trusted_keys. Instead of
>> setting the mok keyring, I’m moving the keys directly into the secondary
>> keyring, while bypassing the current restriction placed on this keyring.
>> Basically I'm trying to follow the same design pattern.
>>
>> If requirements #1, #2 or both (#1 and #2) could be dropped, most of
>> this series would not be necessary.
>
> But without these requirements, the source of trust is unclear.
>
> Is there a reason why the MOK keyring is temporary?
I suppose it doesn't have to be temporary. I was trying not to introduce
another keyring within system_keyring code.
> Asumming a
> function similar to "restrict_link_by_builtin_and_secondary_trusted" is
> defined to include the MOK keyring, the CA keys in the MOK db would be
> loaded onto the MOK keyring, the other keys that meet the secondary
> keyring restriction would be loaded directly onto the secondary
> keyring[1], and as you currently have, the remaining keys onto the
> platform keyring.
>
> This eliminates the exemption needed for loading keys onto the
> secondary keyring. The MOK keyring, containing just CA keys, becomes a
> new trust source.
I just want to make sure I understand. If we kept the .mok keyring around,
we would store it into the system_keyring code, just like the platform
keyring is stored. This would allow the move exemption code to be removed.
If the mok keyring is a new trust source, whenever the secondary keyring
is referenced in verify_ code, the mok keyring will be checked too. If
I have this right, let me know and I’ll work on a v2. Thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Mimi Zohar @ 2021-07-08 19:31 UTC (permalink / raw)
To: Eric Snowberg
Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
Serge E . Hallyn, keescook, gregkh, torvalds, scott.branden,
weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
linux-kernel, linux-crypto, linux-security-module,
James.Bottomley, pjones, glin, konrad.wilk@oracle.com
In-Reply-To: <21EFCB58-2D89-4D30-8DA2-B952A7E1B1BD@oracle.com>
Hi Eric,
On Thu, 2021-07-08 at 11:59 -0600, Eric Snowberg wrote:
>
> > Asumming a
> > function similar to "restrict_link_by_builtin_and_secondary_trusted" is
> > defined to include the MOK keyring, the CA keys in the MOK db would be
> > loaded onto the MOK keyring, the other keys that meet the secondary
> > keyring restriction would be loaded directly onto the secondary
> > keyring[1], and as you currently have, the remaining keys onto the
> > platform keyring.
> >
> > This eliminates the exemption needed for loading keys onto the
> > secondary keyring. The MOK keyring, containing just CA keys, becomes a
> > new trust source.
>
> I just want to make sure I understand. If we kept the .mok keyring around,
> we would store it into the system_keyring code, just like the platform
> keyring is stored. This would allow the move exemption code to be removed.
> If the mok keyring is a new trust source, whenever the secondary keyring
> is referenced in verify_ code, the mok keyring will be checked too. If
> I have this right, let me know and I’ll work on a v2. Thanks.
All the firmware keys are loaded onto the "platform" keyring, without
any restriction. Your reference point should be the "builtin" and
"secondary" keyrings, not the "platform" keyring.
Changes:
- defining a new keyring restriction which only allows CA keys to be
loaded onto the MOK keyring.
- defining a new keyring restriction something along the lines of
"restrict_link_by_builtin_mok_and_secondary_trusted()".
In the case of "restrict_link_by_builtin_and_secondary_trusted()", it's
based on a build time option. In the case of MOK, it might be both a
build time and runtime firmware variable option. There are quite a few
permutations that will somehow need to be addressed: secondary keyring
not defined, but MOK keyring defined, and the reverse.
Once all the CA keys in the MOK db are loaded onto the MOK keyring,
there will be no need for moving keys to the secondary keyring. The
secondary keyring restriction will just work. The main question is
whether there will need to be two passes. One pass to first load all
the CA keys onto the MOK keyring. A second pass to load the keys onto
the secondary keyring, based on the keyring restriction, and the
remaining ones onto the "platform" keyring to avoid the regression.
[Once the CA keys are loaded onto the MOK keyring, userspace will be
able to load certificates, signed by a key on the MOK keyring, onto the
secondary keyring.]
thanks,
Mimi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox