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