Support extending trust store with Linux kernel keyrings

[bureado]

Is your feature request related to a problem?

Modern Linux-based systems use the kernel keyrings (part of a broader kernel service) to determine what keys are trusted by the system.

Among other things, this allows the owner of a system and the owner of the OS image to both contribute keys to the trust store. Inability to use the kernel keyring means that any changes to the trust store need to be reflected in the policy, typically on disk.

What solution do you propose?

Externalize or extend the trust store to use certificates in the kernel keyring, possibly when instructed to do so via a trust policy or an environment variable.

What alternatives have you considered?

The alternative seems to be for a userspace process to walk over the kernel keyrings, perform export operations, reconstruct a trust policy and populate the trust store, which results in duplication, need to synchronize lifecycle events, and more userspace code which increases the attack surface.

For example, the AKV plugin calls for an az keyvault certificate show ... followed by a notation cert add. This is the specific step I'm suggesting we can get rid of by a trust policy potentially indicating it's acceptable for notation to use the kernel keyring as an extended trust store.

I read the documentation on plugins which appears to focus on extending signing mechanisms, not on externalizing trust stores.

Any additional context?

No response

[yizha1]

Thank you @bureado for creating this issue. There is a smiliar issue for windows certificates #721. I think this is a valid ask. If I understand correctly, the request is for the Notary Project trust store to be enhanced to read certificates from the OS system trust store. OS system owners can manage certificates in the system trust store. As a result, normal users won’t need to configure the Notary Project trust store themselves; they would only need to specify which trust store to use in the trust policy and define the trust identities.

[JeyJeyGao]

I have a concern that the notation trust store contains the root certificate that the user trusted specifically for notation verification. However, the system store may contain certificates for other purposes, and other apps may mistakenly add or delete certificates from the system store. Therefore, implicitly using those certificates may not work as expected.

Is it possible to do notation cert add --from-keyrings <certificate-name> ? By doing this, we allow the user to use a certificate from the system store by explicitly selecting the certificate. Also, we don’t need to change the notation trust store to fit both Linux and Windows certificate stores.

[bureado]

There are many certificate stores in Linux. Some are in userspace, others are in kernel space, and they all have various ways to access them.

Kernel keyrings such as builtin_trusted_keys, machine or platform, only allow new keys to be added if you rebuild the kernel or show presence in a machine reboot. Having a key in one of those keyrings mean you can install kernel modules. All of those things are at a higher privilege level than Notation, containerd or anything else.

I'm suggesting a feature that doesn't require notation cert add. I shouldn't need to write a certificate to the Notation trust store that is already stored elsewhere in the system, and rather should be able to have just a pointer. This pointer can be to a single certificate (less ideal) or the entire store. Yes, there should be a way for the trust policy owner to indicate which stores are allowed (or, for example, an environment variable that, instructs notation to only use the trusted kernel keyrings)