mbox series

[0/3] support for duplicate measurement of integrity critical data

Message ID 20210130004519.25106-1-tusharsu@linux.microsoft.com (mailing list archive)
Headers show
Series support for duplicate measurement of integrity critical data | expand

Message

Tushar Sugandhi Jan. 30, 2021, 12:45 a.m. UTC
IMA does not measure duplicate buffer data since TPM extend is a very
expensive operation.  However, in some cases for integrity critical
data, the measurement of duplicate data is necessary to accurately
determine the current state of the system.  Eg, SELinux state changing
from 'audit', to 'enforcing', and back to 'audit' again.  In this
example, currently, IMA will not measure the last state change to
'audit'.  This limits the ability of attestation services to accurately
determine the current state of the integrity critical data on the
system.

This series addresses this gap by providing the ability to measure
duplicate entries for integrity critical data, driven by policy.

This series is based on the following repo/branch/commit:
 repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
 branch: next-integrity-testing
 commit b3f82afc1041 ("IMA: Measure kernel version in early boot") 

Tushar Sugandhi (3):
  IMA: add policy condition to measure duplicate critical data
  IMA: update functions to read allow_dup policy condition
  IMA: add support to measure duplicate buffer for critical data hook

 Documentation/ABI/testing/ima_policy  |  4 +++-
 security/integrity/ima/ima.h          |  8 +++----
 security/integrity/ima/ima_api.c      | 15 +++++++------
 security/integrity/ima/ima_appraise.c |  2 +-
 security/integrity/ima/ima_init.c     |  2 +-
 security/integrity/ima/ima_main.c     |  9 ++++----
 security/integrity/ima/ima_policy.c   | 31 ++++++++++++++++++++++++---
 security/integrity/ima/ima_queue.c    |  5 +++--
 8 files changed, 54 insertions(+), 22 deletions(-)

Comments

Mimi Zohar Feb. 8, 2021, 8:22 p.m. UTC | #1
Hi Tushar,

On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
> IMA does not measure duplicate buffer data since TPM extend is a very
> expensive operation.  However, in some cases for integrity critical
> data, the measurement of duplicate data is necessary to accurately
> determine the current state of the system.  Eg, SELinux state changing
> from 'audit', to 'enforcing', and back to 'audit' again.  In this
> example, currently, IMA will not measure the last state change to
> 'audit'.  This limits the ability of attestation services to accurately
> determine the current state of the integrity critical data on the
> system.
> 
> This series addresses this gap by providing the ability to measure
> duplicate entries for integrity critical data, driven by policy.

The same reason for re-measuring buffer data is equally applicable to
files.  In both cases, the file or the buffer isn't re-measured if it
already exists in the htable.   Please don't limit this patch set to
just buffer data.

thanks,

Mimi
Mimi Zohar Feb. 8, 2021, 9:10 p.m. UTC | #2
Hi Tushar,


On Mon, 2021-02-08 at 15:22 -0500, Mimi Zohar wrote:
> On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
> > IMA does not measure duplicate buffer data since TPM extend is a very
> > expensive operation.  However, in some cases for integrity critical
> > data, the measurement of duplicate data is necessary to accurately
> > determine the current state of the system.  Eg, SELinux state changing
> > from 'audit', to 'enforcing', and back to 'audit' again.  In this
> > example, currently, IMA will not measure the last state change to
> > 'audit'.  This limits the ability of attestation services to accurately
> > determine the current state of the integrity critical data on the
> > system.
> > 
> > This series addresses this gap by providing the ability to measure
> > duplicate entries for integrity critical data, driven by policy.
> 
> The same reason for re-measuring buffer data is equally applicable to
> files.  In both cases, the file or the buffer isn't re-measured if it
> already exists in the htable.   Please don't limit this patch set to
> just buffer data.

Instead of making the change on a per measurement rule basis, disabling
"htable" would be the simplest way of forcing re-measurements.  All
that would be needed is a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE)
and the associated test in ima_add_template_entry().

thanks,

Mimi
Tushar Sugandhi Feb. 9, 2021, 6:23 p.m. UTC | #3
Thank you Mimi for reviewing this series.

On 2021-02-08 1:10 p.m., Mimi Zohar wrote:
> Hi Tushar,
> 
> 
> On Mon, 2021-02-08 at 15:22 -0500, Mimi Zohar wrote:
>> On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
>>> IMA does not measure duplicate buffer data since TPM extend is a very
>>> expensive operation.  However, in some cases for integrity critical
>>> data, the measurement of duplicate data is necessary to accurately
>>> determine the current state of the system.  Eg, SELinux state changing
>>> from 'audit', to 'enforcing', and back to 'audit' again.  In this
>>> example, currently, IMA will not measure the last state change to
>>> 'audit'.  This limits the ability of attestation services to accurately
>>> determine the current state of the integrity critical data on the
>>> system.
>>>
>>> This series addresses this gap by providing the ability to measure
>>> duplicate entries for integrity critical data, driven by policy.
>>
>> The same reason for re-measuring buffer data is equally applicable to
>> files.  In both cases, the file or the buffer isn't re-measured if it
>> already exists in the htable.   Please don't limit this patch set to
>> just buffer data.
> 
Agreed.  I wasn't sure if you wanted the support for files, or other 
buffer measurement scenarios, except critical data.  So I started the 
implementation with supporting just critical data.  Happy to extend it 
to files and other buffer measurement scenarios as you suggested.

> Instead of making the change on a per measurement rule basis, disabling
> "htable" would be the simplest way of forcing re-measurements.  All
> that would be needed is a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE)
> and the associated test in ima_add_template_entry().
> 
Agreed.  Earlier I wasn't sure if you wanted allow_dup support for all 
the scenarios.  Now that it is clear,  I will implement it as you 
suggested.  Thank you so much for the pointers.  Appreciate it.

Thanks,
Tushar

> thanks,
> 
> Mimi
>
Mimi Zohar Feb. 9, 2021, 6:53 p.m. UTC | #4
On Tue, 2021-02-09 at 10:23 -0800, Tushar Sugandhi wrote:
> > On Mon, 2021-02-08 at 15:22 -0500, Mimi Zohar wrote:
> >> On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
> >>> IMA does not measure duplicate buffer data since TPM extend is a very
> >>> expensive operation.  However, in some cases for integrity critical
> >>> data, the measurement of duplicate data is necessary to accurately
> >>> determine the current state of the system.  Eg, SELinux state changing
> >>> from 'audit', to 'enforcing', and back to 'audit' again.  In this
> >>> example, currently, IMA will not measure the last state change to
> >>> 'audit'.  This limits the ability of attestation services to accurately
> >>> determine the current state of the integrity critical data on the
> >>> system.
> >>>
> >>> This series addresses this gap by providing the ability to measure
> >>> duplicate entries for integrity critical data, driven by policy.
> >>
> >> The same reason for re-measuring buffer data is equally applicable to
> >> files.  In both cases, the file or the buffer isn't re-measured if it
> >> already exists in the htable.   Please don't limit this patch set to
> >> just buffer data.
> > 
> Agreed.  I wasn't sure if you wanted the support for files, or other 
> buffer measurement scenarios, except critical data.  So I started the 
> implementation with supporting just critical data.  Happy to extend it 
> to files and other buffer measurement scenarios as you suggested.
> 
> > Instead of making the change on a per measurement rule basis, disabling
> > "htable" would be the simplest way of forcing re-measurements.  All
> > that would be needed is a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE)
> > and the associated test in ima_add_template_entry().
> > 
> Agreed.  Earlier I wasn't sure if you wanted allow_dup support for all 
> the scenarios.  Now that it is clear,  I will implement it as you 
> suggested.  Thank you so much for the pointers.  Appreciate it.

There are two different solutions - per measurement rule, disabling
htable - being discussed.   Disabling htable requires miminumal
changes.  Which version are you thinking of implementing?

thanks,

Mimi
Tushar Sugandhi Feb. 9, 2021, 8:57 p.m. UTC | #5
On 2021-02-09 10:53 a.m., Mimi Zohar wrote:
> On Tue, 2021-02-09 at 10:23 -0800, Tushar Sugandhi wrote:
>>> On Mon, 2021-02-08 at 15:22 -0500, Mimi Zohar wrote:
>>>> On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
>>>>> IMA does not measure duplicate buffer data since TPM extend is a very
>>>>> expensive operation.  However, in some cases for integrity critical
>>>>> data, the measurement of duplicate data is necessary to accurately
>>>>> determine the current state of the system.  Eg, SELinux state changing
>>>>> from 'audit', to 'enforcing', and back to 'audit' again.  In this
>>>>> example, currently, IMA will not measure the last state change to
>>>>> 'audit'.  This limits the ability of attestation services to accurately
>>>>> determine the current state of the integrity critical data on the
>>>>> system.
>>>>>
>>>>> This series addresses this gap by providing the ability to measure
>>>>> duplicate entries for integrity critical data, driven by policy.
>>>>
>>>> The same reason for re-measuring buffer data is equally applicable to
>>>> files.  In both cases, the file or the buffer isn't re-measured if it
>>>> already exists in the htable.   Please don't limit this patch set to
>>>> just buffer data.
>>>
>> Agreed.  I wasn't sure if you wanted the support for files, or other
>> buffer measurement scenarios, except critical data.  So I started the
>> implementation with supporting just critical data.  Happy to extend it
>> to files and other buffer measurement scenarios as you suggested.
>>
>>> Instead of making the change on a per measurement rule basis, disabling
>>> "htable" would be the simplest way of forcing re-measurements.  All
>>> that would be needed is a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE)
>>> and the associated test in ima_add_template_entry().
>>>
>> Agreed.  Earlier I wasn't sure if you wanted allow_dup support for all
>> the scenarios.  Now that it is clear,  I will implement it as you
>> suggested.  Thank you so much for the pointers.  Appreciate it.
> 
> There are two different solutions - per measurement rule, disabling
> htable - being discussed.   Disabling htable requires miminumal
> changes.  Which version are you thinking of implementing?
> 
I am thinking of implementing "disabling 'htable' using a new Kconfig 
(e.g. CONFIG_IMA_DISABLE_HTABLE)".  That is, not using the var 
ima_htable or ima_lookup_digest_entry() if that CONFIG is set.
So the duplicate measurements are allowed when the CONFIG is set.
This would cover all the measurement scenarios through a single CONFIG 
setting.

I am not planning to implement it as a "per measurement rule".

Sorry it wasn't clear in my earlier response.

Thanks,
Tushar

> thanks,
> 
> Mimi
>