Re: [RFC] Issue of historical file and script invocation when using IMA for runtime attestation

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

On Thu, 2025-02-13 at 12:57 +0000, Wang, Nicholas wrote:
> Linux-integrity community,
> 
> Hi, I'm Nicholas Wang from UIUC, and we are researching the potential 
> challenges of a remote runtime attestation tool using IMA, Keylime, under a 
> simulated deployment environment. In the process, we conducted multiple 
> experiments, and we encountered some issues that we realize may not be able to 
> be solved entirely in userspace.
> 
> To sum up the first issue, IMA may not reflect the whole picture of invocation 
> or activation history. In particular, we are in question about "Once the 
> earlier measurements are verified, there is no need to verify them again" 
> according to IMA event log documentation. First off, Keylime uses directories 
> or paths for matching and ignoring files in their policy file; in IMA policy, 
> "dont_measure" filters out filesystems. We see two potential scenarios in which 
> malicious actors may silently bypass the attestation. We assume Keylime user 
> does not use "dont_measure" filters in IMA policy and IMA indeed measured 
> everything while Keylime attest the digests according to its own policy. 
> Keylime would filter and ignore certain files based on its own directories and 
> file filtering, and such ignored files would only appear in IMA log once as long 
> as the system is not rebooted. Now the issue arises: 1. if the file being moved 
> within the same filesystem, it will never re-appear in IMA logs even with 
> further invocations, as IMA treated them the exact same file. This may allow an 
> attack to persist throughout until a fresh reboot. 2. In case of a long-lived 
> system which has patched a vulnerable version of one software, the old, 
> vulnerable version which has been in the IMA log before will not appear in 
> case of further activation before a reboot. Thus, we believe that the design 
> which measures each file once may in some cases not reflect a comprehensive 
> state of the machine to meet runtime attestation needs.

Hi Nicholas,

Can you explain what you mean by "patched"?  In general, software packages on long-lived
systems can and would be updated (e.g. dnf, apt).  The new software would be a different
inode and would be measured on first access.

There's been discussion on resetting the measured/appraised flags after a configurable
period of time, but nobody has actually submitted patches.  There were a couple of ideas:
- Walk the rb tree to reset the measured/appraised flags. (Obsolete)
- Include a timestamp in the iint to detect "expired" measured/appraised flags on access.

I welcome a patch set that enables re-measuring/re-appraising files.

> 
> The other issue we run into is script invocation. We find this is tricky as we 
> realize that scripts being too versatile and hard to enforce the attestation 
> upon execution, and executing them directly (through shebang) versus passing 
> it to interpreters/shell as arguments results in a drastically different 
> attestation result as the latter only attests the interpreter binary itself. 
> While a naive solution would be turning on attestation for file read operations 
> in IMA policy or use SELinux file types to facilitate, however, we suspect it 
> would still be an unmanageable task with unbearable performance. As the nature 
> of the problem is essentially to distinguish code from data, the only 
> reasonable solution we currently have thought is to have interpreters 
> themselves to do the task, and indicate IMA what is code through API. 
> Alternatively, the only probable way would be any attestation tool eventually 
> had to have their own kernel modules and extended file types for IMA policy, 
> and decide on what to be measured in separate components.

Perfect timing.  As Roberto mentioned, you should look at Mickaël Salaün's "[PATCH v23
0/8] Script execution control (was O_MAYEXEC)" patch set.  It was upstreamed in the
current open window (6.14).

Mimi

> 
> We wonder whether there is or has been discussions around these questions. If 
> so, we would like to learn more about any ongoing efforts or plan on changing 
> the current situation, or if not, would like to hear the opinions from the 
> kernel community regarding the two issues.
> 
> Best regards,
> 
> --
> Nicholas Wang