> On Nov 8, 2022, at 6:24 PM, Elaine Palmer <erpalmerny@xxxxxxxxx> wrote: > > > > 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. I would be open to making the changes necessary to support both (A and B) options. What type of configuration option would be considered? Would this be a compile time Kconfig, a Linux boot command line parameter, or another MOK variable?
