From: Sush Shringarputale <sushring@linux.microsoft.com>
To: Stefan Berger <stefanb@linux.ibm.com>,
Tushar Sugandhi <tusharsu@linux.microsoft.com>,
linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
peterhuewe@gmx.de, Jarkko Sakkinen <jarkko@kernel.org>,
jgg@ziepe.ca, Ken Goldman <kgold@linux.ibm.com>,
bhe@redhat.com, vgoyal@redhat.com, Dave Young <dyoung@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
jmorris@namei.org, Paul Moore <paul@paul-moore.com>,
serge@hallyn.com,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-security-module@vger.kernel.org
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Subject: Re: [RFC V2] IMA Log Snapshotting Design Proposal
Date: Tue, 14 Nov 2023 10:36:36 -0800 [thread overview]
Message-ID: <5dfcb0d6-8cbf-428e-b8c1-30333fc668b5@linux.microsoft.com> (raw)
In-Reply-To: <53db2f31-e383-445f-b746-961958a619bd@linux.ibm.com>
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.
- Sush
next prev parent reply other threads:[~2023-11-14 18:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 18:49 [RFC V2] IMA Log Snapshotting Design Proposal Tushar Sugandhi
2023-10-31 18:37 ` Ken Goldman
2023-11-13 18:14 ` Sush Shringarputale
2023-10-31 19:15 ` Mimi Zohar
2023-11-16 22:28 ` Paul Moore
2023-11-22 1:01 ` Tushar Sugandhi
2023-11-22 1:18 ` Mimi Zohar
2023-11-22 4:27 ` Paul Moore
2023-11-22 13:18 ` Mimi Zohar
2023-11-22 14:22 ` Paul Moore
2023-11-27 17:07 ` Mimi Zohar
2023-11-27 22:16 ` Paul Moore
2023-11-28 12:09 ` Mimi Zohar
2023-11-29 1:06 ` Paul Moore
2023-11-29 2:07 ` Mimi Zohar
2024-01-06 23:27 ` Paul Moore
2024-01-07 12:58 ` Mimi Zohar
2024-01-08 2:58 ` Paul Moore
2024-01-08 11:48 ` Mimi Zohar
2024-01-08 17:15 ` Paul Moore
2023-12-20 22:13 ` Ken Goldman
2024-01-06 23:44 ` Paul Moore
2023-11-13 18:59 ` Stefan Berger
2023-11-14 18:36 ` Sush Shringarputale [this message]
2023-11-14 18:58 ` Stefan Berger
2023-11-16 22:07 ` Paul Moore
2023-11-16 22:41 ` Stefan Berger
2023-11-16 22:56 ` Paul Moore
2023-11-17 22:41 ` Sush Shringarputale
2023-11-20 20:03 ` Tushar Sugandhi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5dfcb0d6-8cbf-428e-b8c1-30333fc668b5@linux.microsoft.com \
--to=sushring@linux.microsoft.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jmorris@namei.org \
--cc=kexec@lists.infradead.org \
--cc=kgold@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=peterhuewe@gmx.de \
--cc=serge@hallyn.com \
--cc=stefanb@linux.ibm.com \
--cc=tusharsu@linux.microsoft.com \
--cc=tyhicks@linux.microsoft.com \
--cc=vgoyal@redhat.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox