Re: [RFC] IMA Log Snapshotting Design Proposal - aggregate

[Paul Moore <paul@paul-moore.com>]

On Wed, Sep 6, 2023 at 4:49 PM Ken Goldman <kgold@linux.ibm.com> wrote:
> On 9/1/2023 6:06 PM, Tushar Sugandhi wrote:
> > On 8/30/23 11:12, Ken Goldman wrote:
> >> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
> >>> - A user-mode process will trigger the snapshot by opening a file in
> >>> SysFS
> >>>    say /sys/kernel/security/ima/snapshot (referred to as
> >>> sysk_ima_snapshot_file
> >>>    here onwards).
> >>> - The Kernel will get the current TPM PCR values and PCR update
> >>> counter [2]
> >>>    and store them as template data in a new IMA event
> >>> "snapshot_aggregate".
> >>
> >> If this is relying on a user-mode process, is there a concern that the
> >> process doesn't run. Might it be safer to have the kernel trigger the
> >> snapshot.
> >>
> > The UM process here would be typically an attestation client
> > which passes on the IMA log to the remote service for attestation.
> > If the process doesn't run, the client will operate the same way as it
> > does currently.
>
> I see.
>
> 1. Ensure that the attestation client stores the snapshot in a
> well-known and widely readable location.  There can be more than one
> attestation client, and all need access to the snapshot.

A few points:

* There is no requirement for an admin or solution provider to support
or otherwise use the IMA measurement log snapshotting functionality,
even if enabled in the kernel it is opt-in at runtime (i.e. simply
don't trigger the snapshot).  If the deployment in question is using
an attestation solution which is not compatible with the snapshot
concept then there is no need to perform a snapshot, the system will
behave just as it would today; nothing gained, but nothing lost.

* One of the benefits of initiating the snapshot in userspace is that
it affords solution providers a tremendous amount of flexibility with
respect to how to manage the IMA measurement log.  Not only can
different, and potentially more complex, logic be used to determine
the appropriate time to trigger the snapshot, but the trimmed/old log
can be processed any way the admin sees fit; writing and supporting
userspace code is many orders of magnitude easier than kernel code.

> There is a privacy concern around making the snapshot world-read.

See the above points.  If security requirements can not be satisfied
by any of the various solutions designed to protect the integrity of
system configuration and log data, the snapshotting functionality can
always be blocked at runtime by another collection of access control
solutions.

> 2. Is there a concern that, if the client doesn't run, it doesn't solve
> the kernel memory issue?

Yes, the design relies on a userspace process to initiate, and
complete the snapshotting process.  The good news is that if the
userspace process fails the system is no worse off than it is today,
but modern init-systems, e.g. systemd, should help ensure the
reliability of the userspace snapshot process/daemon.

> Is this relying on a UM process to solve a  kernel issue?

The ultimate problem is that we have an unbounded memory buffer that
we can't enforce limits on in the traditional sense.  The design here
proposes a checkpoint system which allows us to mitigate the
uncontrolled growth of this buffer while preserving the ability to
remotely attest the system (although perhaps with different, or
modified attestation tools).

I have not seen any other options for a viable, kernel driven solution
in any of the discussions thus far, but if you have any suggestions I
think we would all be very interested :)  The tmpfs based solution
doesn't solve the problem of system-wide memory pressure as tmpfs is
still a memory-backed filesystem.  Passing a fd to the kernel is still
a userspace initiated action, with the added problem of requiring the
kernel do the I/O itself.

-- 
paul-moore.com