> On Aug 6, 2021, at 9:18 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
>
> On Fri, 2021-08-06 at 09:00 -0600, Eric Snowberg wrote:
>>> On Aug 5, 2021, at 9:19 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
>>>
>>> On Thu, 2021-08-05 at 19:29 -0600, Eric Snowberg wrote:
>>>
>>>>> From the thread discussion on 00/12:
>>>>>
>>>>> Only the builtin keys should ever be on the builtin keyring. The
>>>>> builtin keyring would need to be linked to the mok keyring. But in the
>>>>> secondary keyring case, the mok keyring would be linked to the
>>>>> secondary keyring, similar to how the builtin keyring is linked to the
>>>>> secondary keyring.
>>>>>
>>>>> if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
>>>>> panic("Can't link trusted keyrings\n");
>>>>
>>>>
>>>> This part is confusing me though.
>>>>
>>>> Here are some of the tests I’m performing with the current series:
>>>>
>>>> Initial setup:
>>>> Create and enroll my own key into the MOK.
>>>> Sign a kernel, kernel module and IMA key with my new CA key.
>>>> Boot with lockdown enabled (to enforce sig validation).
>>>>
>>>> Kernel built with CONFIG_SECONDARY_TRUSTED_KEYRING=y
>>>>
>>>> $ keyctl show %:.secondary_trusted_keys
>>>> Keyring
>>>> 530463486 ---lswrv 0 0 keyring: .secondary_trusted_keys
>>>> 411466727 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys
>>>> 979167715 ---lswrv 0 0 | \_ asymmetric: Build time autogenerated kernel key: 07a56e29cfa1e21379aff2c522efff7d1963202a
>>>> 534573591 ---lswrv 0 0 | \_ asymmetric: Oracle-CA: Oracle certificate signing key: aeefb4bfde095cacaabff81dd266974b1b4e23b8
>>>> 968109018 ---lswrv 0 0 \_ keyring: .mok
>>>> 857795115 ---lswrv 0 0 \_ asymmetric: Erics-CA: UEK signing key: 9bfa6860483aa46bd83f7fa1289d9fc35799e93b
>>>>
>>>> With this setup I can:
>>>> * load a kernel module signed with my CA key
>>>> * run "kexec -ls" with the kernel signed with my CA key
>>>> * run "kexec -ls" with a kernel signed by a key in the platform keyring
>>>> * load another key into the secondary trusted keyring that is signed by my CA key
>>>> * load a key into the ima keyring, signed by my CA key
>>>>
>>>> Kernel built without CONFIG_SECONDARY_TRUSTED_KEYRING defined
>>>>
>>>> $ keyctl show %:.builtin_trusted_keys
>>>> Keyring
>>>> 812785375 ---lswrv 0 0 keyring: .builtin_trusted_keys
>>>> 455418681 ---lswrv 0 0 \_ keyring: .mok
>>>> 910809006 ---lswrv 0 0 | \_ asymmetric: Erics-CA: UEK signing key: 9bfa6860483aa46bd83f7fa1289d9fc35799e93b
>>>> 115345009 ---lswrv 0 0 \_ asymmetric: Oracle-CA: Oracle certificate signing key: aeefb4bfde095cacaabff81dd266974b1b4e23b8
>>>> 513131506 ---lswrv 0 0 \_ asymmetric: Build time autogenerated kernel key: 22353509f203b55b84f15d0aadeddc134b646185
>>>>
>>>> With this setup I can:
>>>> * load a kernel module signed with my CA key
>>>> * run "kexec -ls" with the kernel signed with my CA key
>>>> * run "kexec -ls" with a kernel signed by a key in the platform keyring
>>>> * load a key into the ima keyring, signed by my CA key
>>>>
>>>> So why would the linking need to be switched? Is there a test I’m
>>>> missing? Thanks.
>>>
>>> It's a question of semantics. The builtin keyring name is self
>>> describing. It should only contain the keys compiled into the kernel
>>> or inserted post build into the reserved memory. Not only the kernel
>>> uses the builtin keyring, but userspace may as well[1]. Other users of
>>> the builtin keyring might not want to trust the mok keyring as well.
>>
>> Should this feature only work with kernels built with
>> CONFIG_SECONDARY_TRUSTED_KEYRING defined? If so, I could drop support in
>> the next version for kernels built without it.
>
> Support for loading the CA keys stored in the MOK db onto the mok
> keyring, only if the secondary keyring is configured would really
> simplify the code. Support for using the mok keyring without the
> secondary keyring being configured, could always be added later. As
> long as the other distros agree, I'm all for it.
Agreed, it will simplify the series and there is nothing preventing the
dropped code from being added in the future if a different distro finds
it necessary. I’ll work on this in the next version along with the other
changes you identified. Thanks for your review.
