On Mon, Feb 10, 2020 at 10:25 PM Mimi Zohar [off-list ref] 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.

quoted

quoted

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'.

quoted

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