Re: IMA skips some file measurements

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Mon, 2017-11-06 at 21:26 +0000, Magalhaes, Guilherme (Brazil R&D-
CL) wrote:
> 
> > -----Original Message-----
> > From: Mimi Zohar [mailto:zohar@linux.vnet.ibm.com]
> > Sent: segunda-feira, 6 de novembro de 2017 18:39
> > To: Magalhaes, Guilherme (Brazil R&D-CL)
> > <guilherme.magalhaes@hpe.com>; linux-integrity@vger.kernel.org
> > Subject: Re: IMA skips some file measurements
> > 
> > On Mon, 2017-11-06 at 19:22 +0000, Magalhaes, Guilherme (Brazil R&D-
> > CL) wrote:
> > > We are trying to understand why some file measurements are skipped
> > > by IMA. In some circumstances, it seems that this could lead to an
> > > incorrect assessment of the integrity of the host. Consider the
> > > following, example in which we begin with a vulnerable bash binary
> > > (e.g. Shellshock) and patch it.
> > >
> > > 1. Load vulnerable bash (measured by IMA)
> > > 2. Patch the bash file
> > > 3. Load good bash (measured by IMA)
> > > 4. Change back to vulnerable bash
> > > 5. Load vulnerable bash (not measured by IMA)
> > >
> > > After step 5, the IMA logs appear to tell you that the system is using a
> > > good binary, but a vulnerable binary is installed and being used.
> > >
> > > We identified that 'ima_htable.queue' prevented the measurement at
> > > step 5 since the same vulnerable bash was loaded on step 1 and 5 and
> > > then its respective hash was already present in 'ima_htable.queue'.
> > >
> > > So in this scenario the last/current file state is not identified using the
> > > IMA log. Is it not important to identify through the IMA log whether or
> > > not the last known file state is good?
> > >
> > > Does anybody know why 'ima_htable.queue' is preventing already
> > > logged file hashes from being re-measured?
> > 
> > Yes, we're trying to limit the number of measurements.  This is a last
> > check before adding something already measured to the measurement list
> > and extending the TPM.
> > 
> > For example, a file is removed from dcache, causing the iint to be
> > deleted as well.  The next access would cause the entry to be re-added
> > to the measurement list and extend the TPM for no good reason.
> A side effect for this mechanism is that IMA skips measuring a changed file
> in case the file is changed to a state already measured before, as 
> demonstrated by the example I enumerated above. Then, it could lead to an 
> incorrect integrity assessment considering the last file state/hash may not be 
> in the IMA log.
> 
> So I assume it is a side effect and not working by design. Please, clarify.

The purpose is to prevent duplicate measurements.  So it is clearly
working as designed.  I also don't think the design is flawed.  All
files included in the policy were measured and added to the
measurement list.  If you really want a subsequent measurement with
the same file hash, include the (real) i_ino in the template data.

Mimi