On Mon, 2017-11-06 at 21:26 +0000, Magalhaes, Guilherme (Brazil R&D- CL) wrote: > > > -----Original Message----- > > From: Mimi Zohar [mailto:zohar@xxxxxxxxxxxxxxxxxx] > > Sent: segunda-feira, 6 de novembro de 2017 18:39 > > To: Magalhaes, Guilherme (Brazil R&D-CL) > > <guilherme.magalhaes@xxxxxxx>; linux-integrity@xxxxxxxxxxxxxxx > > 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
