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
