Re: [RFC V2] IMA Log Snapshotting Design Proposal

[Stefan Berger <stefanb@linux.ibm.com>]

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.

Iff the log-shard producer were configured to discard leading parts of 
the log then that should also be noted in a config file so clients, that 
need to see the beginning of the log, can refuse early on to work on a 
machine that either is configured this way or where the discarding has 
already happened.

   Stefan

> - Sush