On Thu, 2021-08-19 at 09:23 -0600, Eric Snowberg wrote:

quoted

On Aug 19, 2021, at 7:10 AM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote:

quoted

On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote:

quoted

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 introduces a new Linux kernel keyring containing the Machine
Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim.

I would name it as ".machine" because it is more "re-usable" name, e.g.
could be used for similar things as MOK. ".mok" is a bad name because
it binds directly to a single piece of user space software.

Nayna previously said,
  "I believe the underlying source from where CA keys are loaded might vary 
  based on the architecture (".mok" is UEFI specific.). The key part is 
  that this new keyring should contain only CA keys which can be later 
  used to vouch for user keys loaded onto IMA or secondary keyring at 
  runtime. It would be good to have a "ca" in the name, like .xxxx-ca, 
  where xxxx can be machine, owner, or system. I prefer .system-ca."

The CA keys on the MOK db is simply the first root of trust being
defined, but other roots of trust are sure to follow.  For this reason,
I agree naming the new keyring "mok" should be avoided.

As I said previously, I’m open to renaming, I just would like to have an 
agreement on the new name before changing everything.  The current proposed 
names I have heard are “.machine" and ".system-ca".  Is there a preference 
the maintainers feel is appropriate?  If so, please let me know and I’ll 
rename it. Thanks.

Just ".system" would be good. It's informative enough.


/Jarkko