2021-08-12 02:21:17

by Eric Snowberg

Subject: [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok

With the introduction of the mok keyring, the end-user may choose to
trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
trust them, the .mok keyring will contain these keys. If not, the mok
keyring will always be empty. Update the restriction check to allow the
secondary trusted keyring to also trust mok keys.

Signed-off-by: Eric Snowberg <[email protected]>
---
v3: Initial version
---
certs/system_keyring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index cb773e09ea67..8cc19a1ff051 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
if (!restriction)
panic("Can't allocate secondary trusted keyring restriction\n");

- restriction->check = restrict_link_by_builtin_and_secondary_trusted;
+ restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;

return restriction;
}
--
2.18.4

2021-08-12 20:41:17

by Mimi Zohar

Subject: Re: [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok

Hi Eric,

On Wed, 2021-08-11 at 22:18 -0400, Eric Snowberg wrote:
> With the introduction of the mok keyring, the end-user may choose to
> trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
> trust them, the .mok keyring will contain these keys. If not, the mok
> keyring will always be empty. Update the restriction check to allow the
> secondary trusted keyring to also trust mok keys.
>
> Signed-off-by: Eric Snowberg <[email protected]>
> ---
> v3: Initial version
> ---
> certs/system_keyring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index cb773e09ea67..8cc19a1ff051 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
> if (!restriction)
> panic("Can't allocate secondary trusted keyring restriction\n");
>
> - restriction->check = restrict_link_by_builtin_and_secondary_trusted;
> + restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;
>
> return restriction;
> }

Not everyone needs to build a generic kernel, like the distros. As
previously discussed, not everyone is willing to trust the new MOK
keyring nor the UEFI variable for enabling it. For those environments,
they should be able to totally disable the MOK keyring.

Please define a Kconfig similar to "CONFIG_SECONDARY_TRUSTED_KEYRING"
for MOK. The "restriction" would be based on the new Kconfig being
enabled.

thanks,

Mimi

2021-08-12 23:39:14

by Eric Snowberg

Subject: Re: [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok

> On Aug 12, 2021, at 1:46 PM, Mimi Zohar <[email protected]> wrote:
>
> Hi Eric,
>
> On Wed, 2021-08-11 at 22:18 -0400, Eric Snowberg wrote:
>> With the introduction of the mok keyring, the end-user may choose to
>> trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
>> trust them, the .mok keyring will contain these keys. If not, the mok
>> keyring will always be empty. Update the restriction check to allow the
>> secondary trusted keyring to also trust mok keys.
>>
>> Signed-off-by: Eric Snowberg <[email protected]>
>> ---
>> v3: Initial version
>> ---
>> certs/system_keyring.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index cb773e09ea67..8cc19a1ff051 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
>> if (!restriction)
>> panic("Can't allocate secondary trusted keyring restriction\n");
>>
>> - restriction->check = restrict_link_by_builtin_and_secondary_trusted;
>> + restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;
>>
>> return restriction;
>> }
>
> Not everyone needs to build a generic kernel, like the distros. As
> previously discussed, not everyone is willing to trust the new MOK
> keyring nor the UEFI variable for enabling it. For those environments,
> they should be able to totally disable the MOK keyring.
>
> Please define a Kconfig similar to "CONFIG_SECONDARY_TRUSTED_KEYRING"
> for MOK. The "restriction" would be based on the new Kconfig being
> enabled.

Yes, I can add that. Currently there is a Kconfig to enable the secondary
and another for IMA to trust the secondary. Would you like to see two new
Kconfig options added? One that allows the secondary to use the mok as a new
trust source and another for IMA to trust the mok keyring. Or a single Kconfig
that handles both? Thanks.

2021-08-12 23:39:14

by Mimi Zohar

Subject: Re: [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok

On Thu, 2021-08-12 at 16:10 -0600, Eric Snowberg wrote:
> > On Aug 12, 2021, at 1:46 PM, Mimi Zohar <[email protected]> wrote:
> >
> > On Wed, 2021-08-11 at 22:18 -0400, Eric Snowberg wrote:
> >> With the introduction of the mok keyring, the end-user may choose to
> >> trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
> >> trust them, the .mok keyring will contain these keys. If not, the mok
> >> keyring will always be empty. Update the restriction check to allow the
> >> secondary trusted keyring to also trust mok keys.
> >>
> >> Signed-off-by: Eric Snowberg <[email protected]>
> >> ---
> >> v3: Initial version
> >> ---
> >> certs/system_keyring.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> >> index cb773e09ea67..8cc19a1ff051 100644
> >> --- a/certs/system_keyring.c
> >> +++ b/certs/system_keyring.c
> >> @@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
> >> if (!restriction)
> >> panic("Can't allocate secondary trusted keyring restriction\n");
> >>
> >> - restriction->check = restrict_link_by_builtin_and_secondary_trusted;
> >> + restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;
> >>
> >> return restriction;
> >> }
> >
> > Not everyone needs to build a generic kernel, like the distros. As
> > previously discussed, not everyone is willing to trust the new MOK
> > keyring nor the UEFI variable for enabling it. For those environments,
> > they should be able to totally disable the MOK keyring.
> >
> > Please define a Kconfig similar to "CONFIG_SECONDARY_TRUSTED_KEYRING"
> > for MOK. The "restriction" would be based on the new Kconfig being
> > enabled.
>
> Yes, I can add that. Currently there is a Kconfig to enable the secondary
> and another for IMA to trust the secondary. Would you like to see two new
> Kconfig options added? One that allows the secondary to use the mok as a new
> trust source and another for IMA to trust the mok keyring. Or a single Kconfig
> that handles both? Thanks.

A single Kconfig option for enabling the new keyring should be fine.

thanks,

Mimi