Re: [RFC] Persist ima logs to disk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 1/8/2021 4:38 AM, Mimi Zohar wrote:
On Thu, 2021-01-07 at 14:57 -0800, Raphael Gianotti wrote:
But this doesn't address where the offloaded measurement list
will be stored, how long the list will be retained, nor who
guarantees the integrity of the offloaded list.  In addition,
different form factors will have different requirements.
For how long the list would be retained, or in the case of a log segments, it
might make sense to have that be an admin decision, something that can be
configured to satisfy the needs of a specific system, as mentioned below by
James, does that seem correct?
For the discussion on exporting and truncating the IMA measurement
list, refer to:
https://lore.kernel.org/linux-integrity/1580998432.5585.411.camel@xxxxxxxxxxxxx/

Given the possibility of keeping the logs around for an indefinite amount of
time, would using an expansion of the method present in this RFC be more
appropriate than going down the vfs_tmpfile route? Forgive my lack on expertise
on mm, but would the vfs_tmpfile approach work for keeping several log segments
across multiple kexecs?
With the "vfs_tmpfile" mechanism, breaking up and saving the log in
segments isn't needed.  The existing mechanism for carrying the
measurement list across kexec would still be used.  Currently, if the
kernel cannot allocate the memory needed for carrying the measurement
across kexec, it simply emits an error message, but continues with the
kexec.

In this change I had introduced "exporting" the log to disk when the size
of the measurement list was too large. Given part of the motivation behind
moving the measurement list is the possibility of it growing too large
and taking up too much of the kernel memory, that case would likely lead
to kexec not being able to carry over the logs. Do you believe it's better
to use the "vfs_tmpfile" mechanism for moving the logs to disk and worry
about potential issues with kexec not being able to carry over the logs
separately, given the "vfs_tempfile" approach seems to be preferred and
also simplifies worries regarding truncating the logs?


Mimi



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux