On Mon, 2020-02-10 at 15:24 -0500, Mimi Zohar wrote:

On Mon, 2020-02-10 at 13:18 -0500, david.safford@gmail.com wrote:

quoted

On Thu, 2020-02-06 at 09:13 -0500, Mimi Zohar wrote:

quoted

Hi Janne,

On Fri, 2020-01-10 at 10:48 +0200, Janne Karhunen wrote:

quoted

On Wed, Jan 8, 2020 at 1:18 PM Janne Karhunen [off-list ref] wrote:

quoted

Some systems can end up carrying lots of entries in the ima
measurement list. Since every entry is using a bit of kernel
memory, allow the sysadmin to export the measurement list to
the filesystem to free up some memory.

Hopefully this addressed comments from everyone. The flush event can
now be triggered by the admin anytime and unique file names can be
used for each flush (log.1, log.2, ...) etc, so getting to the correct
item should be easy.

While it can now be argued that since this is an admin-driven event,
kernel does not need to write the file. However, the intention is to
bring out a second patch a bit later that adds a variable to define
the max number of entries to be kept in the kernel memory and
workqueue based automatic flushing. In those cases the kernel has to
be able to write the file without any help from the admin..

The implications of exporting and removing records from the IMA-
measurement list needs to be considered carefully.  Verifying a TPM
quote will become dependent on knowing where the measurements are
stored.  The existing measurement list is stored in kernel memory and,
barring a kernel memory attack, is protected from modification.
 Before upstreaming this or a similar patch, there needs to be a
discussion as to how the measurement list will be protected once is it
exported to userspace.

"Protected" here can mean two different aspects: cryptographically
protected from tampering, which is covered with the TPM_QUOTE, and
availability protected from even accidental deletion, which is what
I suspect you are concerned about. Certainly my original TLV patches
were too flippant about this, as userspace had to be trusted not to
drop any records. In this patch, the kernel writes the data in an
atomic fashion. Either all records are successfully written, or none
are, and an error is returned.

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.

This is a feature, not a bug. :-)
There is no reason to resend the same data for every attestation,
nor is there any reason to store already attested measurements anywhere
on the client. By versioning the log file names, userspace gets a
simple way to know what has and has not been attested, and for small
embedded devices we don't need to waste memory or filesystem space
on the data already attested.

When Thiago and I added support for carrying the measurement list
across kexec, there were a number of additional measurements after the
kexec load.  These additional measurements will need to be safely
written out to file in order to validate the TPM quote.

quoted

I have been testing this patch on all of these scenarios, and it
provides a simple, powerful approach for all of them.

 
Were you able to walk the measurement list and validate the TPM quote
after a kexec?

I'm still working on this. (I've mainly been making sure this works
for normal template and TLV lists.) I should be able to write out the
remaining kexec measurements, but haven't actually validated that
yet...

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 method of exporting is atomic, so only those items exported
get deleted.

quoted

quoted

In the kernel usecase, somehow the kernel would need to safely export
the measurement list, or some portion of the measurement list, to a
file and then delete that portion.  What protects the exported records
stored in a file from modification?

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.

The userspace attestation process has always been able to tamper or
delete the list data during its attestation, but we can detect this
remotely.

quoted

quoted

Instead of exporting the measurement records, one option as suggested
by Amir Goldstein, would be to use a vfs_tmpfile() to get an anonymous
file for backing store.  The existing securityfs measurement lists
would then read from this private copy of the anonymous file.

This doesn't help in use cases where we really do want to
export to a persistent file, without userspace help.

Is to prevent needing to carry the measurement list across kexec the
only reason for the kernel needing to write to a persistent file?

Well, that and the other reasons mentioned, such as completely freeing
the data from the client after attestation, and simplicity of the
mechanism.

dave

Mimi