On 2022/11/04 9:20 AM, Coiby Xu wrote: > Hi Eric, > > I wonder if there is any update on this work? I would be glad to do > anything that may be helpful including testing a new version of code. > Hi Coiby, Yes, this discussion got stuck when we couldn't agree on one of the following options: (A) Filter which keys from MOK (or a management system) are loaded onto the .machine keyring. Specifically, load only keys with CA+keyCertSign attributes. (B) Load all keys from MOK (or a management system) onto the .machine keyring. Then, subsequently filter those to restrict which ones can be loaded onto the .ima keyring specifically. The objection to (A) was that distros would have to go through two steps instead of one to load keys. The one-step method of loading keys was supported by an out-of-tree patch and then by the addition of the .machine keyring. The objection to (B) was that, because the .machine keyring is now linked to the .secondary keyring, it expands the scope of what the kernel has trusted in the past. The effect is that keys in MOK have the same broad scope as keys previously restricted to .builtin and .secondary. It doesn't affect just IMA, but the rest of the kernel as well. I would suggest that we can get unstuck by considering: (C) Defining a systemd (or dracut module) to load keys onto the .secondary keyring (D) Using a configuration option to specify what types of .machine keys should be allowed to pass through to the .secondary keyring. The distro could choose (A) by allowing only CA+keyCertSign keys. The distro could choose (B) by allowing any kind of key. We all seemed to agree that enforcing key usage should be implemented and that a useful future effort is to add policies to keys and keyrings, like, "This key can only be used for verifying kernel modules." I hope we can come to an agreement so work can proceed and IMA can be re-enabled. -Elaine Palmer
