IMA skips some file measurements

IMA skips some file measurements

[Magalhaes, Guilherme (Brazil R&D-CL)]

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?

--
Guilherme

Re: IMA skips some file measurements

[Mikhail Kurinnoi]

? Mon, 6 Nov 2017 19:22:55 +0000
"Magalhaes, Guilherme (Brazil R&D-CL)" <guilherme.magalhaes@hpe.com>
?????:

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

As I understood, you have FS mounted with i_version option, after step 2
IMA hash was updated in file IMA xattr (plus, in ima_check_last_writer()
iint->measured_pcrs was set to 0 in order to measure changed file next
time again), but in step 5 file not measured by IMA? Right?



-- 
Best regards,
Mikhail Kurinnoi

RE: IMA skips some file measurements

[Magalhaes, Guilherme (Brazil R&D-CL)]

> -----Original Message-----
> From: Mikhail Kurinnoi [mailto:viewizard@gmail.com] On Behalf Of Mikhail
> Kurinnoi
> Sent: segunda-feira, 6 de novembro de 2017 18:05
> To: Magalhaes, Guilherme (Brazil R&D-CL) <guilherme.magalhaes@hpe.com>
> Cc: linux-integrity@vger.kernel.org
> Subject: Re: IMA skips some file measurements
> 
> ? Mon, 6 Nov 2017 19:22:55 +0000
> "Magalhaes, Guilherme (Brazil R&D-CL)" <guilherme.magalhaes@hpe.com>
> ?????:
> 
> > 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?
> >
> > --
> > Guilherme
> >
> 
> As I understood, you have FS mounted with i_version option, after step 2
> IMA hash was updated in file IMA xattr (plus, in ima_check_last_writer()
> iint->measured_pcrs was set to 0 in order to measure changed file next
> time again), but in step 5 file not measured by IMA? Right?
That's correct. Check the use of ima_htable.queue in ima_lookup_digest_entry().
It prevents ima_add_template_entry() from actually measuring the changed file 
if the 'new' hash is already present in that hash table.

--
Guilherme

> 
> 
> 
> --
> Best regards,
> Mikhail Kurinnoi

Re: IMA skips some file measurements

[Mimi Zohar]

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.

Mimi

RE: IMA skips some file measurements

[Magalhaes, Guilherme (Brazil R&D-CL)]

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

--
Guilherme

> 
> Mimi

Re: IMA skips some file measurements

[Mimi Zohar]

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