[PATCH v2] ima: export the measurement list when needed

[Janne Karhunen]

On Fri, Jan 24, 2020 at 4:46 PM <david.safford at 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, allow the sysadmin to export the measurement list to
> > the filesystem to free up some memory.
> >
> > Signed-off-by: Janne Karhunen <janne.karhunen at gmail.com>
>
> I like this approach, as it will work easily for measurement lists in
> any format, and it will work for user or kernel triggering.

Yes, that was the point..


> I'm getting an OOPS, though, whenever I write a filename to the
> securityfs file (e.g. echo /var/log/ima.log > list_name).
> Here's the relevant from syslog:
>
>   BUG: unable to handle page fault for address: 00005650a0e7fe30
>   #PF: supervisor read access in kernel mode
>   #PF: error_code(0x0001) - permissions violation
>
>   Oops: 0001 [#1] SMP NOPTI
>
>   RIP: 0010:ima_write_list_name+0x35/0x114
>
> I haven't had time to debug this. Any suggestions?

Interesting. I'm not a X86 man, but it looks like a SMAP trap to me.
In other words, the kernel was not allowed to read that
"/var/log/ima.log" string as SMAP protection was active for that piece
of memory. I was under the impression that the SMAP is disabled while
the copy_from_user is running..

I'll try on the X86 hardware and see if I can reproduce, maybe its off
by one read or something. Only X86 target I tested was QEMU.


> > +#define secfs_mnt    "/sys/kernel/security"
> > +#define am_filename  "/integrity/ima/ascii_runtime_measurements"
>
> You probably really want to export the binary data, as that's
> what's needed for attestation. (Or both, but that's trickier.)

That's why the file name was left as an argument to the export
function; you can export either one. I suppose we'd need some setting
to tell it which one to export.


--
Janne