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
