On Thu, Nov 16, 2023 at 5:41 PM Stefan Berger <stefanb@xxxxxxxxxxxxx> wrote: > On 11/16/23 17:07, Paul Moore wrote: > > On Tue, Nov 14, 2023 at 1:58 PM Stefan Berger <stefanb@xxxxxxxxxxxxx> 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. Yes, performing a snapshot is a privileged operation which I expect would be done and managed by a dedicated daemon running on the system. -- paul-moore.com
