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

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

[Wang, Nicholas]

[-- 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 --]

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

[Roberto Sassu]

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@digikod.net/


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

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

[Mimi Zohar]

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

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

[Wang, Nicholas]

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

Hi,

Thank you both Roberto and Mimi for your timely replies! I have been 
discussing with our collaborators since and we believe the information 
definitely helps us more on understanding the issue from IMA's perspective. 
While I cannot immediately give a comprehensive reply, I can quickly clarify 
some of it whichever I can.

On Friday, 14 February 2025 14:30:42 CST Zohar, Mimi wrote:
> 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.

By patched I meant exactly updated to a patched version, and I believe in most 
cases your arguments should hold: old executable is either directly 
overwritten, or been deleted and then replaced with new version by the package 
manager. HOWEVER, I believe the inode assumption does not apply to the 
scenarios I tried to describe. In case 1, assuming attacker "moves" the file, 
inode would stay the same, result would be that executable being executed in a 
new directory without reflecting in the IMA log; In case 2, assuming a software 
is updated, new binary now has a new inode, and is executed therefore attested 
by IMA after update. IMA log now shows an entry of the vulnerable version, as 
well as an entry of the updated version, with the same path. Now if attacker 
replace updated executable with the previous vulnerable version at the exact 
same path, based on our testing, further execution of the vulnerable version 
would never cause a third entry to appear in IMA log, regardless inode is same 
or different (as long as it has identical path to the first (vulnerable version 
exec.) IMA log entry). 

> 
> 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.

Thanks for the information and we will look into the past discussions and 
further discuss with our team, see if we would propose a feasible solution and 
potentially submit a patch set to upstream.

> > 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

--
Nicholas Wang

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

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

[Mimi Zohar]

On Tue, 2025-02-18 at 18:06 +0000, Wang, Nicholas wrote:
> Hi,
> 
> Thank you both Roberto and Mimi for your timely replies! I have been 
> discussing with our collaborators since and we believe the information 
> definitely helps us more on understanding the issue from IMA's perspective. 
> While I cannot immediately give a comprehensive reply, I can quickly clarify 
> some of it whichever I can.
> 
> On Friday, 14 February 2025 14:30:42 CST Zohar, Mimi wrote:
> > 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.
> 
> By patched I meant exactly updated to a patched version, and I believe in most 
> cases your arguments should hold: old executable is either directly 
> overwritten, or been deleted and then replaced with new version by the package 
> manager. HOWEVER, I believe the inode assumption does not apply to the 
> scenarios I tried to describe. In case 1, assuming attacker "moves" the file, 
> inode would stay the same, result would be that executable being executed in a 
> new directory without reflecting in the IMA log; In case 2, assuming a software 
> is updated, new binary now has a new inode, and is executed therefore attested 
> by IMA after update. IMA log now shows an entry of the vulnerable version, as 
> well as an entry of the updated version, with the same path. Now if attacker 
> replace updated executable with the previous vulnerable version at the exact 
> same path, based on our testing, further execution of the vulnerable version 
> would never cause a third entry to appear in IMA log, regardless inode is same 
> or different (as long as it has identical path to the first (vulnerable version 
> exec.) IMA log entry).

Hi Nicholas,

Right, the renamed file (case 1) would not be re-measured unless the file was also
modified.  As Roberto explained, the file name is part of the directory, not metadata
associated with the inode.  Refer to the getdents man page.

The case 2 concern was addressed by enabling CONFIG_IMA_DISABLE_HTABLE.  For an
explanation, please refer to commit 52c208397c24 ("IMA: support for duplicate measurement
records") patch description.

> 
> > 
> > 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.
> 
> Thanks for the information and we will look into the past discussions and 
> further discuss with our team, see if we would propose a feasible solution and 
> potentially submit a patch set to upstream.

Sounds good.

Mimi