Re: [RFC] Persist ima logs to disk

[Mimi Zohar <zohar@linux.ibm.com>]

On Thu, 2021-01-07 at 12:37 -0800, James Bottomley wrote:
> On Thu, 2021-01-07 at 15:02 -0500, Mimi Zohar wrote:
> > On Thu, 2021-01-07 at 08:42 -0800, James Bottomley wrote:
> > > On Thu, 2021-01-07 at 10:06 -0500, Mimi Zohar wrote:
> > > > [Cc: Amir Goldstein]
> > > > 
> > > > On Tue, 2021-01-05 at 11:57 -0800, Raphael Gianotti wrote:
> > > > > IMA measures files and buffer data and some systems may end up
> > > > > generating lots of entries in the IMA measurement list. This
> > > > > list is kept in kernel memoryc and as it grows in size it could
> > > > > end up taking too many resources, causing the system to run out
> > > > > of available memory. During kexec, the IMA measurement list can
> > > > > be carried over in memory, but it's possible for the list to
> > > > > become too large for that to happen.
> > > > > 
> > > > > The Kconfig introduced in this series enables admins to
> > > > > configure a maximum number of entries and a file to export the
> > > > > IMA measurement list to whenever the set limit is reached.
> > > > > 
> > > > > The list is written out in append mode, so the system will keep
> > > > > writing new entries as long as it stays running or runs out of
> > > > > space. Whenever the export file is set, it's truncated. If
> > > > > writing to the export list fails, a flag is set to prevent
> > > > > further exports, as the file is likely in a bad state. Setting
> > > > > a new export file resets this flag, allowing exports to resume
> > > > > and giving admins a way to recover from this state if
> > > > > necessary.
> > > > > 
> > > > > In the case of kexec, if the list is too large too be carried
> > > > > over in memory and an export file is configured, the list will
> > > > > be exported, preventing the measurements from being lost during
> > > > > kexec.
> > > > > 
> > > > > This code is based off of a previous RFC sent by Janne
> > > > > Karhunen[1], and is intended to pick up where that was left
> > > > > off.
> > > > > 
> > > > > In a thread with Janne Karhunen[2], it was mentioned that
> > > > > another approach, using mm had been considered. Upon some
> > > > > investigation the approach used in this RFC still seemed
> > > > > adequate for solving this problem.
> > > > > 
> > > > > [1] 
> > > > > https://patchwork.kernel.org/project/linux-integrity/patch/201912
> > > > > 20074929.8191-1-janne.karhunen@gmail.com/
> > > > > [2] 
> > > > > https://lore.kernel.org/linux-integrity/CAE=NcrbdS-3gVvnnEwdNSOLO
> > > > > vTenLjyppDz2aJACGRgBYSh=Gw@mail.gmail.com/
> > > > > 
> > > > > Signed-off-by: Raphael Gianotti <raphgi@linux.microsoft.com>
> > > > 
> > > > My original concerns of truncating the IMA measurement list have
> > > > not been addressed.  Once the IMA measurement list has been
> > > > truncated, quoting and then verifying any of the PCRs contained
> > > > in the measurement list will fail, unless the measurements have
> > > > been preserved and are readily accessible.
> > > > 
> > > > Amir's suggestion addresses kernel memory constraints without
> > > > truncating the IMA measurement list.
> > > 
> > > What about having a log entry that's the current PCR value?  Then
> > > stretches of the log starting with these entries would be
> > > independently verifiable provided you had a way of trusting the PCR
> > > value.  It might be possible to get the TPM to add a signed quote
> > > as an optional part of the log entry (of course this brings other
> > > problems like which key do you use for the signing and how does it
> > > get verified) which would provide the trust and would definitively
> > > allow you to archive log segments and still make the rest of the
> > > log useful.
> > 
> > The current PCR values are aggregated and stored in the
> > boot_aggregate record.  As part of the new boot_aggregate record
> > format, the individual PCR values could be included.
> 
> I don't think we care about the boot aggregate ... it's just the
> initial log entry that ties the boot state to the initial runtime
> state.  All we need for the proposed entry is the current value of the
> IMA PCR so provided you trust that value it becomes a base on which the
> following measurements can build and be trusted.

The IMA measurement list may contain multiple PCRs, not just the
default IMA PCR.   Each kexec results in an additional boot_aggregate
record, but an equivalent record for after truncating the measurement
list might help.
> 
> > But this doesn't address where the offloaded measurement list will be
> > stored, how long the list will be retained, nor who guarantees the
> > integrity of the offloaded list.  In addition, different form factors
> > will have different requirements.
> 
> I'm not sure you need any store at all.  The basic idea is that the log
> is divided into individually verifiable segments.  For auditing
> purposes you could keep all segments, so you have the entire log, but
> if you've acted on the prior log entries and you don't have an audit
> reason to keep them, you could erase that segment of the log because
> you've placed all your trust in the prior log segments into the PCR
> entry that forms the base of your current segment.
> 
> Essentially the question devolves to what mechanisms can give you this
> trust in the base PCR log entry.

Not retaining the entire measurement list would limit it's verification
to a single server/system.

Mimi