Re: [PATCH v1 - RFC] ima: export the measurement list when needed

Re: [PATCH v1 - RFC] ima: export the measurement list when needed

[Mimi Zohar]

[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@gmail.com>

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@ALPMBAPA12.e2k.ad.ge.com/

Re: [PATCH v1 - RFC] ima: export the measurement list when needed

[Janne Karhunen]

On Fri, Dec 20, 2019 at 4:04 PM Mimi Zohar <zohar@linux.ibm.com> wrote:

> 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?

That is a good question. I went this way as it did not feel right to
me that the kernel would depend on periodic, reliable userspace
functionality to stay running (we would have a circular dependency).
The thing is, once the kernel starts to run low on memory, it may kill
that periodic daemon flushing the data for reasons unrelated to IMA.


-- 
Janne

Re: [PATCH v1 - RFC] ima: export the measurement list when needed

[Janne Karhunen]

On Sat, Dec 21, 2019 at 12:41 PM Janne Karhunen
<janne.karhunen@gmail.com> wrote:

> > 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?
>
> That is a good question. I went this way as it did not feel right to
> me that the kernel would depend on periodic, reliable userspace
> functionality to stay running (we would have a circular dependency).
> The thing is, once the kernel starts to run low on memory, it may kill
> that periodic daemon flushing the data for reasons unrelated to IMA.

Besides the dependency, I think the requirement should be that we can
survive the basic test of 'while true; do touch $RANDOM; done' at
least until we run out of allocated diskspace. While arranging this
with userspace flushers is not impossible, it is order of magnitude
more complex to do correctly than just letting the kernel write the
file. Even if it feels somewhat unorthodox.

Above patch survives that test case with 3 line addition via a
workqueue. Once the admin points IMA to some mount, the above test
case (while loop creating files full speed) will run a long, long
time. Effectively this is really just kernel doing its own memory
management as it should. Flush out the dirty pages you do not really
need to stay running.


--
Janne

Re: [PATCH v1 - RFC] ima: export the measurement list when needed

[david.safford]

On Sat, 2019-12-21 at 12:41 +0200, Janne Karhunen wrote:
> On Fri, Dec 20, 2019 at 4:04 PM Mimi Zohar <zohar@linux.ibm.com>
> wrote:
> 
> > 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?
> 
> That is a good question. I went this way as it did not feel right to
> me that the kernel would depend on periodic, reliable userspace
> functionality to stay running (we would have a circular dependency).
> The thing is, once the kernel starts to run low on memory, it may
> kill
> that periodic daemon flushing the data for reasons unrelated to IMA.
> 

I'm happy with either way (kernel writing, or userspace reading) the
data, but with the v1 patch, there is no way for userspace to force
that the list be flushed - it only flushes on full. I think it is 
important for userspace to be able to trigger a flush, such as just
prior to a kexec, or prior to an attestation. 

Perhaps you could simply remove the length test in ima_export_list(),
and export anytime the filename is provided? This could simplify
attestation clients, which could ask for different files each time
(list.1, list.2...), for automatic log maintenance. Since the template
format does not have sequence numbers, this would also help keep
track which records have already been seen.

dave

Re: [PATCH v1 - RFC] ima: export the measurement list when needed

[Janne Karhunen]

On Tue, Dec 24, 2019 at 5:35 PM <david.safford@gmail.com> wrote:

> > That is a good question. I went this way as it did not feel right to
> > me that the kernel would depend on periodic, reliable userspace
> > functionality to stay running (we would have a circular dependency).
> > The thing is, once the kernel starts to run low on memory, it may
> > kill
> > that periodic daemon flushing the data for reasons unrelated to IMA.
> >
>
> I'm happy with either way (kernel writing, or userspace reading) the
> data, but with the v1 patch, there is no way for userspace to force
> that the list be flushed - it only flushes on full. I think it is
> important for userspace to be able to trigger a flush, such as just
> prior to a kexec, or prior to an attestation.

Indeed, will add in v2.


> Perhaps you could simply remove the length test in ima_export_list(),
> and export anytime the filename is provided? This could simplify
> attestation clients, which could ask for different files each time
> (list.1, list.2...), for automatic log maintenance. Since the template
> format does not have sequence numbers, this would also help keep
> track which records have already been seen.

Yes, will do something like this. Holidays cause some latency here,
but I will send an update next week.


--
Janne