On Thu, 2021-01-07 at 10:06 -0500, Mimi Zohar wrote:

[Cc: Amir Goldstein]

On Tue, 2021-01-05 at 11:57 -0800, Raphael Gianotti wrote:

quoted

IMA measures files and buffer data and some systems may end up
generating lots of entries in the IMA measurement list. This list
is kept in kernel memoryc and as it grows in size it could end up
taking too many resources, causing the system to run out of
available memory. During kexec, the IMA measurement list can be
carried over in memory, but it's possible for the list to become
too large for that to happen.

The Kconfig introduced in this series enables admins to configure a
maximum number of entries and a file to export the IMA measurement
list to whenever the set limit is reached.

The list is written out in append mode, so the system will keep
writing new entries as long as it stays running or runs out of
space. Whenever the export file is set, it's truncated. If writing
to the export list fails, a flag is set to prevent further exports,
as the file is likely in a bad state. Setting a new export file
resets this flag, allowing exports to resume and giving admins a
way to recover from this state if necessary.

In the case of kexec, if the list is too large too be carried over
in memory and an export file is configured, the list will be
exported, preventing the measurements from being lost during kexec.

This code is based off of a previous RFC sent by Janne Karhunen[1],
and is intended to pick up where that was left off.

In a thread with Janne Karhunen[2], it was mentioned that another
approach, using mm had been considered. Upon some investigation the
approach used in this RFC still seemed adequate for solving this
problem.

[1] 
https://patchwork.kernel.org/project/linux-integrity/patch/201912
20074929.8191-1-janne.karhunen@gmail.com/
[2] 
https://lore.kernel.org/linux-integrity/CAE=NcrbdS-3gVvnnEwdNSOLO
vTenLjyppDz2aJACGRgBYSh=Gw@mail.gmail.com/

Signed-off-by: Raphael Gianotti <redacted>

My original concerns of truncating the IMA measurement list have not
been addressed.  Once the IMA measurement list has been truncated,
quoting and then verifying any of the PCRs contained in the
measurement list will fail, unless the measurements have been
preserved and are readily accessible.

Amir's suggestion addresses kernel memory constraints without
truncating the IMA measurement list.

What about having a log entry that's the current PCR value?  Then
stretches of the log starting with these entries would be independently
verifiable provided you had a way of trusting the PCR value.  It might
be possible to get the TPM to add a signed quote as an optional part of
the log entry (of course this brings other problems like which key do
you use for the signing and how does it get verified) which would
provide the trust and would definitively allow you to archive log
segments and still make the rest of the log useful.

James