Blob Blame History Raw
From de8bbb63dca836bcf07586186218c3227749d2e7 Mon Sep 17 00:00:00 2001
From: Stefan Berger <stefanb@linux.ibm.com>
Date: Fri, 4 Nov 2022 11:20:15 -0400
Subject: [PATCH] ima: Fix log evaluation on quick-succession execution of
 scripts

In case the attested-to host quickly executes files measured by IMA we may
run into the case that the keylime agent retrieved the state of the PCR at
'state n' but then IMA appended the log with several entries leading to a
log representing 'state n + x' (with x>=1), which may not just be the
previously anticipated single additional entry (state n+1). Therefore,
remove the check for the number of entries in the log and always compare
the running_hash that iterative attestation was resumed with against the
provided PCR value from 'state n'.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
 keylime/ima/ima.py | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/keylime/ima/ima.py b/keylime/ima/ima.py
index b88b1af..c4c2ae6 100644
--- a/keylime/ima/ima.py
+++ b/keylime/ima/ima.py
@@ -299,9 +299,11 @@ def _process_measurement_list(
 
     # Iterative attestation may send us no log [len(lines) == 1]; compare last know PCR 10 state
     # against current PCR state.
-    # Since IMA log append and PCR extend is not atomic, we may get a quote that does not yet take
-    # into account the next appended measurement's [len(lines) == 2] PCR extension.
-    if not found_pcr and len(lines) <= 2:
+    # Since IMA's append to the log and PCR extend as well as Keylime's retrieval of the quote, reading
+    # of PCR 10 and retrieval of the log are not atomic, we may get a quote that does not yet take into
+    # account the next-appended measurements' [len(lines) >= 2] PCR extension(s). In fact, the value of
+    # the PCR may lag the log by several entries.
+    if not found_pcr:
         found_pcr = running_hash == pcrval_bytes
 
     for linenum, line in enumerate(lines):
-- 
2.37.3