On Fri, 2019-10-04 at 12:29 -0700, Lakshmi Ramasubramanian wrote: > On 9/19/19 10:12 AM, Mimi Zohar wrote: > > Hi Mimi, > > > On 9/1 I commented on this patch set from a technical perspective, > > saying: > > > IMA measures, appraises, and audits files based on policy[1]. If > > you're going to measure keys, all of the code should be within the IMA > > subdirectory. The only code outside of the IMA subdirectory is either > > an LSM or IMA hook. If an LSM hook already exists, use it. If an LSM > > hook doesn't exist and the location is generic that other LSMs would > > be interested, define a new LSM hook, otherwise define a new IMA hook. > > I am having trouble addressing the above feedback. Appreciate if you > could provide guidance: > > The key(s) in the trusted keys keyring (builtin, secondary, etc.) are > added early in the kernel boot process. But IMA is initialized later. > If I have a LSM\IMA hook, that gets called when key(s) are added to the > trusted keys keyring, I won't be able to invoke IMA on "key add" since > IMA is not yet initialized. > > Right now, I have the key measurement function in ima_init. I can gate > that based on policy (similar to how Prakhar has done kexec_cmdline > measurement) and follow the coding guidelines you have pointed to. > But it would still have to call keyring function to get the list of keys > in the trusted keys keyring. > > Are you fine if I take the above approach? > > If not, could you please suggest a better way to handle it that meets > the kernel layering guidelines? IMA is late because it is waiting for the TPM to be available. Another option would be to queue the measurements and then replay them once the TPM and IMA are available. I'm not sure I like this approach any better. Mimi
