[Cc'ing LSM mailing list for a wider audience]
On Fri, 2019-12-20 at 09:49 +0200, Janne Karhunen wrote:
> Some systems can end up carrying lots of entries in the ima
> measurement list. Since every entry is using a bit of kernel
> memory, add a new Kconfig variable to allow the sysadmin to
> define the maximum measurement list size and the location
> of the exported list.
>
> 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. File is also automatically truncated on startup.
>
> Signed-off-by: Janne Karhunen <janne.karhunen@xxxxxxxxx>
Continually adding new measurements, without limiting or removing the
measurement list seems to becoming more of an issue.
>From Dave Safford's TLV patch description[1]:
A second goal of the [TLV] patch set is to test the more radical
idea of being able to copy the measurement list data out of the
kernel. The data is verifiable with the TPM PCR value, and need not
be kept in kernel memory. In some cases, this "memory leak" can
grow large enough to cause issues, and this is a test of a
potential way to solve that problem.
The TLV version automatically removed the measurement list the first
time the measurement list was read, which sounded very odd to me. In
an offline discussion, Dave further clarified that reading the
measurement list should be similar to how a trusted userspace
application reads kernel messages. The difference being kernel
messages are stored in a circular buffer and may be dropped. In the
IMA measurement list case, the measurement list would grow until the
trusted userspace application gets around to reading the measurement
list.
Should the kernel be involved in writing the IMA measurement list to a
file or, as Dave suggested, this should be delegated to a userspace
application?
Mimi
[1] https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4
D4A3C002569222@xxxxxxxxxxxxxxxxxxxxxxxx/
