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. Hi Nicholas thanks a lot for your questions. Will try to answer to the best of my knowledge. > 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. I think the basic principle of the dont_measure rules, is that the files in the pseudo filesystems are kernel-controlled, meaning that they don't have random content but they have to be formatted according to what the kernel expects (needs to be verified if it is the case). Sure, also tmpfs is skipped, but in this case the initial state is that the volume is empty and it is the running system filling it. It is more a problem of run-time integrity, rather than load-time. > 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 Yes, we are not giving trusted path guarantees. In the past there was a patch set from Dmitry Kasatkin about directory protection (https://lwn.net/Articles/574221/), but the work didn't progress. What matters from the IMA point of view is what the process reads, as it has the potential of corrupting the process. From where data are read, it is not relevant for the purpose of assessing whether or not the process got access to malicious data. > 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. Yes, we still need to have a good rollback detection, for example by adding a measurement of outdated binaries. We still need to come up with a good solution. > 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. Michael Salakun upstreamed a patch set to let the interpreters query the kernel (also IMA) on whether or not a script should be executed: https://lore.kernel.org/linux-integrity/20241212174223.389435-1-mic@xxxxxxxxxxx/ Following on that, Mimi upstreamed a patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/security/integrity/ima/ima_main.c?h=v6.14-rc2&id=95b3cdafd7cb74414070893445a9b731793f7b55 that makes IMA measure scripts even if they are passed as argument to the interpreter. All the interpreters need to be extended to make such kernel query, but potentially scripts would be measured regardless of how they are invoked. Roberto > 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
