[RFC] IMA Log Snapshotting Design Proposal

[Paul Moore]

On Tue, Aug 29, 2023 at 5:54 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> On Tue, 2023-08-29 at 17:30 -0400, Paul Moore wrote:
> > On Tue, Aug 29, 2023 at 5:05 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> > > On Tue, 2023-08-29 at 15:34 -0400, Paul Moore wrote:
> > > > On Mon, Aug 21, 2023 at 7:08 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> > > > > On Mon, 2023-08-21 at 15:05 -0700, Sush Shringarputale wrote:
> > > > > > On 8/14/2023 3:02 PM, Mimi Zohar wrote:
> > > > > > > On Mon, 2023-08-14 at 14:42 -0700, Sush Shringarputale wrote:
> > > > > > >>> This design seems overly complex and requires synchronization between
> > > > > > >>> the "snapshot" record and exporting the records from the measurement
> > > > > > >>> list.  None of this would be necessary if the measurements were copied
> > > > > > >>> from kernel memory to a backing file (e.g. tmpfs), as described in [1].
> > > > > > Even if the Kernel maintains the link between a tmpfs exported and an
> > > > > > in-memory IMA log - it still has to copy the tmpfs portion to the
> > > > > > Kernel memory during kexec soft boot.  tmpfs is cleared during kexec,
> > > > > > so this copying of tmpfs back to kernel memory is necessary to preserve
> > > > > > the integrity of the log during kexec.  But the copying would add back
> > > > > > the memory pressure on the node during kexec (which may result in
> > > > > > out-of-memory), defeating the purpose of the overall effort/feature.
> > > > > > Copying to a regular *persistent* protected file seems a cleaner
> > > > > > approach, compared to tmpfs.
> > > > >
> > > > > From a kernel perspective, it doesn't make a difference if userspace
> > > > > provides a tmpfs or persistent file.  As per the discussion
> > > > > https://lore.kernel.org/linux-integrity/CAOQ4uxj4Pv2Wr1wgvBCDR-tnA5dsZT3rvdDzKgAH1aEV_-r9Qg@mail.gmail.com/#t
> > > > > , userspace provides the kernel with the file descriptor of the opened
> > > > > file.
> > > > >
> > > > > > We prototyped this solution, however it
> > > > > > does not seem to be a common pattern within the Kernel to write state
> > > > > > directly to files on disk file systems.  We considered two potential
> > > > > > options:
> > > > >
> > > > > If no file descriptor is provided, then the measurements aren't copied
> > > > > and removed from the securityfs file.  If there are write errors, the
> > > > > measurements aren't removed from the securityfs file until the write
> > > > > errors are resolved.
> > > >
> > > > It sounds like this approach would require the file/filesystem to be
> > > > continuously available for the life of the system once the log was
> > > > snapshotted/overflowed to persistent storage, yes?  Assuming that is
> > > > the case, what happens if the file/filesystem becomes inaccessible at
> > > > some point and an attestation client attempts to read the entire log?
> > >
> > > The main purpose of the change is to addres kernel memory pressure.
> > > Two designs are being discussed: Sush's "snapshotting" design and
> > > Amir's original suggestion of continously exporting the measurement
> > > records to a tmpfs or regular file.  Both designs require verifying the
> > > initial attestation quote by walking the entire measurement list,
> > > calculating the expected TPM PCR value(s).  That doesn't change.
> >
> > Sure, but my question is about what happens if portions of the
> > measurement list disappear due to file/filesystem problems?  How is
> > that handled?
>
> With the "snapshotting" solution there could be multiple files, so
> portions could be missing.  The other solution, the preferred solution,
> would be one file.

With the snapshotting approach the kernel doesn't need to maintain
ongoing access to a file, that is left up to the user process
performing the attestation (or simply inspecting the logs).  I have to
ask, for the third time now in as many hours, how does the proposed
kernel-holds-an-fd-open solution handle the case where the
file/filesystem is no longer accessible?  The snapshotting approach
should be much more resilient here as the error recovery paths can be
much more involved than what we would have available in the kernel,
not to mention the flexibility of allowing a user process to determine
how to store and manage the snapshotted log.

Considering that the snapshotting approach is opt-in (userspace has to
initiate the snapshot), I'm not sure the concern over log offsets is a
significant objection: existing userspace will never trigger a
snapshot, and new userspace that could potentially trigger a snapshot
should be written to take that into account.

-- 
paul-moore.com