On Wed, Sep 6, 2023 at 4:49 PM Ken Goldman <kgold@xxxxxxxxxxxxx> 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
