On Mon, Feb 10, 2020 at 10:25 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > A third aspect, which I'm concerned about, is removing records from > the measurement list. This changes the existing userspace > expectations of returning the entire measurement list. Now userspace > will need some out of band method of knowing where to look for the > measurements. Well, the original patch has a mechanism with one bit flip. You can read the list name given that you are in the right namespace and/or mount. > > > The kernel already exports the IMA measurement list to userspace via a > > > securityfs file. From a userspace perspective, missing is the ability > > > of removing N number of records. In this scenario, userspace would be > > > responsible for safely storing the measurements (e.g. blockchain). > > > The kernel would only be responsible for limiting permission, perhaps > > > based on a capability, before removing records from the measurement > > > list. > > > > I don't think we want to export 'N' records, as this would > > be really hard to understand and coordinate with userspace. > > Exporting all or none seems simpler. > > Userspace already has the ability of exporting the measurement list. > However, beetween saving the measurement list to a file and telling > the kernel to delete the records from the kernel, additional > measurement could have been added. This is not an issue as long as there is no 'ALL' alias. We can't agree on what 'ALL' is, but we can agree on 'N'. > > Tampering is prevented with the TPM_QUOTE. Accidental deletion is > > protected with CAP_SYS_ADMIN. If CAP_SYS_ADMIN is untrusted, you > > have bigger problems, and even then it will be detected. > > Agreed, attestation will detect any tampering, but up to now we didn't > have to rely on DAC/MAC to prevent tampering of the measurement list. True. How about storing a hmac of the file in a securityfs entry? -- Janne
