Re: [RFC] Persist ima logs to disk

[Mimi Zohar <zohar@linux.ibm.com>]

On Tue, 2021-02-02 at 07:54 +0200, Amir Goldstein wrote:
> On Tue, Feb 2, 2021 at 12:53 AM Raphael Gianotti
> <raphgi@linux.microsoft.com> wrote:
> >
> >
> > On 1/8/2021 9:58 AM, Raphael Gianotti wrote:
> > >
> > > 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@linux.ibm.com/
> > >>
> > >>
> > >>> 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?
> >
> > After a chat with Mimi I went ahead and did some investigative
> > work in the vfs_tmpfile approach suggested, and I wanted to
> > restart this thread with some thoughts/questions that came up
> > from that.
> > For the work I did I simply created a tmp file during ima's
> > initialization and then tried to use vm_mmap to map it to memory,
> > with the goal of using that memory mapping to generate return
> > pointers to the code that writes the measurement entries to memory.
> 
> I don't understand why you would want to do that. I might have misunderstood
> the requirements, but this was not how I meant for tmpfile to be used.
> 
> Mimi explained to me that currently the IMA measurement list is entirely in
> memory and that you are looking for a way to dump it into a file in order to
> free up memory.
> 
> What I suggested is this:
> 
> - User opens an O_TMPFILE and passes fd to IMA to start export
> - IMA starts writing (exporting) records to that file using *kernel* write API
> - Every record written to the file is removed from the in-memory list
> - While list is being exported, IMA keeps in-memory count of exported entries
> - In ima_measurements_start, if export file exists, start iterator
> starts reading
>   records from the file
> - In ima_measurements_next(), when next iterator reaches the export count,
>   it switches over to iterate in-memory list
> 
> This process can:
> 1. Continue forever without maintaining any in-memory list
> 2. Work in the background to periodically flush list to file
> 3. Controlled by explicit user commands
> 4. All of the above
> 
> Is that understood? Did I understand the requirements correctly?

Thanks, Amir!

One of the main requirements we discussed was protecting the O_TMPFILE,
not allowing userspace direct access to the file.

Mimi