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

["Wang, Nicholas" <chenkai3@illinois.edu>]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

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.

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.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]