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

[Janne Karhunen <janne.karhunen@gmail.com>]

Hi Raphael,

It depends how well you make it, if you do it right you would not lose
them. If the pagefile has a readable format it should all be safe,
right?


--
Janne

On Mon, Aug 31, 2020 at 7:49 PM Raphael Gianotti
<raphgi@linux.microsoft.com> wrote:
>
> Hi Janne,
>
> Thanks for your response, I didn't reply right away as I hadn't used mm
> and vmarea via vfs_tmpfile before, so I wanted to read some code to
> familiarize myself with it. Correct me if I am misunderstanding the
> approach you mentioned, but in it, we would still lose the logs accross
> kexec/cold boots as we do today, is that correct? It feels like this
> approach would solely solve the issue where we can potentially run out
> of memory for ima logs.
>
> For the original approach, I have a prototype version that I intend to
> send as an RFC soon (I will link you and it's based off of your original
> RFC from late last year).
>
> - Raphael
>
> On 8/26/2020 7:12 AM, Janne Karhunen wrote:
> > Hi,
> >
> > Come to think of it, there could be a MM trap though as I'm not sure
> > this has been done before. This new file vmarea would sit in the
> > kernel virtual memory area somewhere above the page_offset and the mm
> > code might assume that there is no need to look for dirty pages there
> > when running the PTE scan. But that shouldn't be more than one line
> > patch if that is the only trap..
> >
> >
> > --
> > Janne
> >
> > On Wed, Aug 26, 2020 at 4:40 PM Janne Karhunen <janne.karhunen@gmail.com> wrote:
> >> Hi,
> >>
> >> Attached a variant of the patch from that time that only does the
> >> element free and relies on the userspace reading the data.
> >>
> >> The reason why I stopped working on this at the time was that below
> >> was sufficient for my needs. However, after a discussion between Mimi
> >> and myself (based on a suggestion by Amir Goldstein) we realized that
> >> we could do something considerably more elegant through vfs_tmpfile.
> >> It's also much more work.
> >>
> >> The way this could probably work the best is if we would implement a
> >> new allocator that would pull pages from a vmarea tied to a
> >> vfs_tmpfile and the file could be opened by the kernel itself during
> >> the ima init. Now if all the measurement list data blobs would be
> >> allocated through this allocator the pages would never be permanently
> >> resident in the kernel, they would only visit the memory for a while
> >> when someone reads the data. If done this way the allocator probably
> >> does not even need a 'free' and the mm code would do all the real work
> >> pushing the data out.
> >>
> >> The benefits would be that no-one would ever have to poll from
> >> userspace (kernel does not depend on the userspace to work) and we
> >> would never OOM because of IMA as long as the filesystem is writable.
> >> Also we would never lose any data as long as the file system is
> >> functioning.
> >>
> >> Thoughts?
> >>
> >>
> >> --
> >> Janne
> >>
> >> On Wed, Aug 26, 2020 at 11:14 AM Janne Karhunen
> >> <janne.karhunen@gmail.com> wrote:
> >>> Hi Raphael,
> >>>
> >>> Sorry I missed the reply. I'm not working on this right now, feel free
> >>> to grab. Please copy me with the results, thank you.
> >>>
> >>>
> >>> --
> >>> Janne
> >>>
> >>> On Tue, Aug 18, 2020 at 12:30 AM Raphael Gianotti
> >>> <raphgi@linux.microsoft.com> wrote:
> >>>>
> >>>> Hi Janne,
> >>>>
> >>>> Subject: Re: [RFC] ima: export the measurement list when needed
> >>>>> Date: Wed, 18 Dec 2019 17:11:22 +0200
> >>>>> From: Janne Karhunen <janne.karhunen@gmail.com>
> >>>>> To: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>
> >>>>> CC: Ken Goldman <kgold@linux.ibm.com>, david.safford@gmail.com,
> >>>>> monty.wiseman@ge.com
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Have in mind that below is the first trial draft that booted and
> >>>>> seemingly accomplished the task once, it was not really tested at all
> >>>>> yet. I will make a polished and tested version if people like the
> >>>>> concept.
> >>>>>
> >>>>> Note that the code (almost) supports pushing and pulling of the
> >>>>> entries. This variant is a simple pull given that the list size is
> >>>>> above the defined limits. Pushing can be put in place if the recursion
> >>>>> with the list extend_list_mutex is cleared, maybe this could be done
> >>>>> via another patch later on when we have a workqueue for the export
> >>>>> task? The workqueue might be the best context for the export job since
> >>>>> clearing the list is a heavy operation (and it's not entirely correct
> >>>>> here AFAIK, there is no rcu sync before the template free).
> >>>>>
> >>>>>
> >>>>> -- Janne
> >>>>>
> >>>>> On Wed, Dec 18, 2019 at 2:53 PM Janne Karhunen
> >>>>> <janne.karhunen@gmail.com> 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>
> >>>>>> ---
> >>>>>>   security/integrity/ima/Kconfig     |  10 ++
> >>>>>>   security/integrity/ima/ima.h       |   7 +-
> >>>>>>   security/integrity/ima/ima_fs.c    | 178 +++++++++++++++++++++++++++++
> >>>>>>   security/integrity/ima/ima_queue.c |   2 +-
> >>>>>>   4 files changed, 192 insertions(+), 5 deletions(-)
> >>>> I've been looking into a solution to this same issue you started some
> >>>> work on. I was wondering if you are still working on it. I was
> >>>> considering taking your initial prototyping on this and extending it
> >>>> into a final solution, but I wanted to reply here first and check if you
> >>>> are currently working on this.
> >>>>