[RFC V2] IMA Log Snapshotting Design Proposal

[Sush Shringarputale]

On 11/16/2023 2:56 PM, Paul Moore wrote:
> On Thu, Nov 16, 2023 at 5:41 PM Stefan Berger <stefanb at linux.ibm.com> wrote:
>> On 11/16/23 17:07, Paul Moore wrote:
>>> On Tue, Nov 14, 2023 at 1:58 PM Stefan Berger <stefanb at linux.ibm.com> wrote:
>>>> On 11/14/23 13:36, Sush Shringarputale wrote:
>>>>> On 11/13/2023 10:59 AM, Stefan Berger wrote:
>>>>>> On 10/19/23 14:49, Tushar Sugandhi wrote:
>>>>>>> =======================================================================
>>>>>>> | Introduction |
>>>>>>> =======================================================================
>>>>>>> This document provides a detailed overview of the proposed Kernel
>>>>>>> feature IMA log snapshotting.  It describes the motivation behind the
>>>>>>> proposal, the problem to be solved, a detailed solution design with
>>>>>>> examples, and describes the changes to be made in the clients/services
>>>>>>> which are part of remote-attestation system.  This is the 2nd version
>>>>>>> of the proposal.  The first version is present here[1].
>>>>>>>
>>>>>>> Table of Contents:
>>>>>>> ------------------
>>>>>>> A. Motivation and Background
>>>>>>> B. Goals and Non-Goals
>>>>>>>        B.1 Goals
>>>>>>>        B.2 Non-Goals
>>>>>>> C. Proposed Solution
>>>>>>>        C.1 Solution Summary
>>>>>>>        C.2 High-level Work-flow
>>>>>>> D. Detailed Design
>>>>>>>        D.1 Snapshot Aggregate Event
>>>>>>>        D.2 Snapshot Triggering Mechanism
>>>>>>>        D.3 Choosing A Persistent Storage Location For Snapshots
>>>>>>>        D.4 Remote-Attestation Client/Service-side Changes
>>>>>>>            D.4.a Client-side Changes
>>>>>>>            D.4.b Service-side Changes
>>>>>>> E. Example Walk-through
>>>>>>> F. Other Design Considerations
>>>>>>> G. References
>>>>>>>
>>>>>> Userspace applications will have to know
>>>>>> a) where are the shard files?
>>>>> We describe the file storage location choices in section D.3, but user
>>>>> applications will have to query the well-known location described there.
>>>>>> b) how do I read the shard files while locking out the producer of the
>>>>>> shard files?
>>>>>>
>>>>>> IMO, this will require a well known config file and a locking method
>>>>>> (flock) so that user space applications can work together in this new
>>>>>> environment. The lock could be defined in the config file or just be
>>>>>> the config file itself.
>>>>> The flock is a good idea for co-ordination between UM clients. While
>>>>> the Kernel cannot enforce any access in this way, any UM process that
>>>>> is planning on triggering the snapshot mechanism should follow that
>>>>> protocol.  We will ensure we document that as the best-practices in
>>>>> the patch series.
>>>> It's more than 'best practices'. You need a well-known config file with
>>>> well-known config options in it.
>>>>
>>>> All clients that were previously just trying to read new bytes from the
>>>> IMA log cannot do this anymore in the presence of a log shard producer
>>>> but have to also learn that a new log shard has been produced so they
>>>> need to figure out the new position in the log where to read from. So
>>>> maybe a counter in a config file should indicate to the log readers that
>>>> a new log has been produced -- otherwise they would have to monitor all
>>>> the log shard files or the log shard file's size.
>>> If a counter is needed, I would suggest placing it somewhere other
>>> than the config file so that we can enforce limited write access to
>>> the config file.
>>>
>>> Regardless, I imagine there are a few ways one could synchronize
>>> various userspace applications such that they see a consistent view of
>>> the decomposed log state, and the good news is that the approach
>>> described here is opt-in from a userspace perspective.  If the
>> A FUSE filesystem that stitches together the log shards from one or
>> multiple files + IMA log file(s) could make this approach transparent
>> for as long as log shards are not thrown away. Presumably it (or root)
>> could bind-mount its files over the two IMA log files.
>>
>>> userspace does not fully support IMA log snapshotting then it never
>>> needs to trigger it and the system behaves as it does today; on the
>> I don't think individual applications should trigger it , instead some
>> dedicated background process running on a machine would do that every n
>> log entries or so and possibly offer the FUSE filesystem at the same
>> time. In either case, once any application triggers it, all either have
>> to know how to deal with the shards or FUSE would make it completely
>> transparent.
FUSE would be a reasonable user space co-ordination implementation.  A
privileged process would trigger the snapshot generation and provide the
mountpoint to read the full IMA log backed by shards as needed by relying
parties.

Whether it is a privileged daemon or some other agent that triggers the
snapshot, it shouldn't impact the Kernel-side implementation.

- Sush
> Yes, performing a snapshot is a privileged operation which I expect
> would be done and managed by a dedicated daemon running on the system.
>