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@xxxxxxxxx/ > > > > > [2] > > > > > https://lore.kernel.org/linux-integrity/CAE=NcrbdS-3gVvnnEwdNSOLO > > > > > vTenLjyppDz2aJACGRgBYSh=Gw@xxxxxxxxxxxxxx/ > > > > > > > > > > Signed-off-by: Raphael Gianotti <raphgi@xxxxxxxxxxxxxxxxxxx> > > > > > > > > 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
