On 11/16/23 14: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.
Agreed. The counter shouldn't be part of a config file.
IMA log already provides a trustworthy, tamper-resilient mechanism
to store such data.
The current design already provides the mechanism to store
the counter as part of the snapshot_aggregate event.
See section "D.1 Snapshot Aggregate Event" in the proposal for
reference.
Snapshot_Counter := "Snapshot_Attempt_Count="
<num. snapshot attempts>
"snapshot_aggregate" becomes the first event recorded in the
in-memory IMA log, after the past entries are purged to
a shard file. Along with the other benefits, the "snapshot_aggregate"
event also provides info to UM clients about how many snapshots are
taken so far.
See section "C.2 High-level Work-flow" in the proposal for more
info.
Step #f
---------
(In-memory IMA log)
.----------------------.
| "snapshot_aggregate" |
| Event #E4 |
| Event #E5 |
'----------------------'
~Tushar
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
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
other hand, if the userspace has been updated it can make use of the
new functionality to better manage the size of the IMA measurement
log.
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
