IMA does not measure duplicate data since TPM extend is a very expensive
operation. However, in some cases, 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 measurements
on the system.
Update ima_add_template_entry() to support measurement of duplicate
data, driven by a Kconfig option - IMA_DISABLE_HTABLE.
Signed-off-by: Tushar Sugandhi <[email protected]>
---
Change Log v2:
- Incorporated feedback from Mimi on v1.
- The fix is not just applicable to measurement of critical data,
it now applies to other buffers and file data as well.
- the fix is driven by a Kconfig option IMA_DISABLE_HTABLE, rather
than a IMA policy condition - allow_dup.
security/integrity/ima/Kconfig | 7 +++++++
security/integrity/ima/ima_queue.c | 5 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 12e9250c1bec..057c20b46587 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -334,3 +334,10 @@ config IMA_SECURE_AND_OR_TRUSTED_BOOT
help
This option is selected by architectures to enable secure and/or
trusted boot based on IMA runtime policies.
+
+config IMA_DISABLE_HTABLE
+ bool "disable htable to allow measurement of duplicate data"
+ depends on IMA
+ default n
+ help
+ This option disables htable to allow measurement of duplicate data.
diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
index c096ef8945c7..532da87ce519 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -168,7 +168,7 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
int result = 0, tpmresult = 0;
mutex_lock(&ima_extend_list_mutex);
- if (!violation) {
+ if (!violation && !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE)) {
if (ima_lookup_digest_entry(digest, entry->pcr)) {
audit_cause = "hash_exists";
result = -EEXIST;
@@ -176,7 +176,8 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
}
}
- result = ima_add_digest_entry(entry, 1);
+ result = ima_add_digest_entry(entry,
+ !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE));
if (result < 0) {
audit_cause = "ENOMEM";
audit_info = 0;
--
2.17.1
Hi Tushar,
The Subject line could be improved. Perhaps something like - "IMA:
support for duplicate measurement records"
On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote:
> IMA does not measure duplicate data since TPM extend is a very expensive
> operation. However, in some cases, 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 measurements
> on the system.
This patch description is written from your specific usecase
perspective, but it impacts file and buffer data measurements as well,
not only critical data measurements. In all of these situations, with
this patch a new measurement record is added/appended to the
measurement list. Please re-write the patch description making it more
generic.
For example, I would start with something like, "IMA does not include
duplicate file, buffer or critical data measurement records ..."
thanks,
Mimi
>
> Update ima_add_template_entry() to support measurement of duplicate
> data, driven by a Kconfig option - IMA_DISABLE_HTABLE.
>
> Signed-off-by: Tushar Sugandhi <[email protected]>
On 2021-02-17 12:39 p.m., Mimi Zohar wrote:
> On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote:
>> Thanks for the feedback Mimi.
>> Appreciate it.
>>
>> On 2021-02-17 7:03 a.m., Mimi Zohar wrote:
>>> Hi Tushar,
>>>
>>> The Subject line could be improved. Perhaps something like - "IMA:
>>> support for duplicate measurement records"
>>>
>> Will do.
>>
>>> On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote:
>>>> IMA does not measure duplicate data since TPM extend is a very expensive
>>>> operation. However, in some cases, 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 measurements
>>>> on the system.
>>>
>>> This patch description is written from your specific usecase
>>> perspective, but it impacts file and buffer data measurements as well,
>>> not only critical data measurements. In all of these situations, with
>>> this patch a new measurement record is added/appended to the
>>> measurement list. Please re-write the patch description making it more
>>> generic.
>>>
>>> For example, I would start with something like, "IMA does not include
>>> duplicate file, buffer or critical data measurement records ..."
>>>
>> Agreed.
>> I will generalize the description further and send the v3 for review.
>
> It would be good to boot with the ima_policy=tcb policy with/without
> your patch and account for the different number of measurements. Are
> all the differences related to duplicate measurements - original file
> hash -> new file hash -> original file hash - similar to what you
> described.
>
Thanks for the ima_policy=tcb pointer.
I tested my patch with:
- duplicate buffer content for "measure func=CRITICAL_DATA"
- and reading the same file twice with "measure func=FILE_CHECK
mask=MAY_READ"
In both the above use cases, IMA is measuring the duplicate entries with
the patch, and not measuring the duplicate entries w/o the patch.
I will test the "ima_policy=tcb" boot-scenario as you suggested, before
posting the next version.
Thanks,
Tushar
> thanks,
>
> Mimi
>
On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote:
> Thanks for the feedback Mimi.
> Appreciate it.
>
> On 2021-02-17 7:03 a.m., Mimi Zohar wrote:
> > Hi Tushar,
> >
> > The Subject line could be improved. Perhaps something like - "IMA:
> > support for duplicate measurement records"
> >
> Will do.
>
> > On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote:
> >> IMA does not measure duplicate data since TPM extend is a very expensive
> >> operation. However, in some cases, 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 measurements
> >> on the system.
> >
> > This patch description is written from your specific usecase
> > perspective, but it impacts file and buffer data measurements as well,
> > not only critical data measurements. In all of these situations, with
> > this patch a new measurement record is added/appended to the
> > measurement list. Please re-write the patch description making it more
> > generic.
> >
> > For example, I would start with something like, "IMA does not include
> > duplicate file, buffer or critical data measurement records ..."
> >
> Agreed.
> I will generalize the description further and send the v3 for review.
It would be good to boot with the ima_policy=tcb policy with/without
your patch and account for the different number of measurements. Are
all the differences related to duplicate measurements - original file
hash -> new file hash -> original file hash - similar to what you
described.
thanks,
Mimi
Thanks for the feedback Mimi.
Appreciate it.
On 2021-02-17 7:03 a.m., Mimi Zohar wrote:
> Hi Tushar,
>
> The Subject line could be improved. Perhaps something like - "IMA:
> support for duplicate measurement records"
>
Will do.
> On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote:
>> IMA does not measure duplicate data since TPM extend is a very expensive
>> operation. However, in some cases, 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 measurements
>> on the system.
>
> This patch description is written from your specific usecase
> perspective, but it impacts file and buffer data measurements as well,
> not only critical data measurements. In all of these situations, with
> this patch a new measurement record is added/appended to the
> measurement list. Please re-write the patch description making it more
> generic.
>
> For example, I would start with something like, "IMA does not include
> duplicate file, buffer or critical data measurement records ..."
>
Agreed.
I will generalize the description further and send the v3 for review.
Thanks,
Tushar
> thanks,
>
> Mimi
>
>>
>> Update ima_add_template_entry() to support measurement of duplicate
>> data, driven by a Kconfig option - IMA_DISABLE_HTABLE.
>>
>> Signed-off-by: Tushar Sugandhi <[email protected]>
Hi Mimi,
On 2021-02-17 12:49 p.m., Tushar Sugandhi wrote:
>
>
> On 2021-02-17 12:39 p.m., Mimi Zohar wrote:
>> On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote:
>>> Thanks for the feedback Mimi.
>>> Appreciate it.
>>>
>>> On 2021-02-17 7:03 a.m., Mimi Zohar wrote:
>>>> Hi Tushar,
>>>>
>>>> The Subject line could be improved.? Perhaps something like - "IMA:
>>>> support for duplicate measurement records"
>>>>
>>> Will do.
>>>
>>>> On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote:
>>>>> IMA does not measure duplicate data since TPM extend is a very
>>>>> expensive
>>>>> operation.? However, in some cases, 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 measurements
>>>>> on the system.
>>>>
>>>> This patch description is written from your specific usecase
>>>> perspective, but it impacts file and buffer data measurements as well,
>>>> not only critical data measurements.? In all of these situations, with
>>>> this patch a new measurement record is added/appended to the
>>>> measurement list.? Please re-write the patch description making it more
>>>> generic.
>>>>
>>>> For example, I would start with something like, "IMA does not include
>>>> duplicate file, buffer or critical data measurement records ..."
>>>>
>>> Agreed.
>>> I will generalize the description further and send the v3 for review.
>>
>> It would be good to boot with the ima_policy=tcb policy with/without
>> your patch and account for the different number of measurements.?? Are
>> all the differences related to duplicate measurements - original file
>> hash -> new file hash -> original file hash - similar to what you
>> described.
>>
> Thanks for the ima_policy=tcb pointer.
>
> I tested my patch with:
> ?- duplicate buffer content for "measure func=CRITICAL_DATA"
> ?- and reading the same file twice with "measure func=FILE_CHECK
> mask=MAY_READ"
>
> In both the above use cases, IMA is measuring the duplicate entries with
> the patch, and not measuring the duplicate entries w/o the patch.
>
> I will test the "ima_policy=tcb" boot-scenario as you suggested, before
> posting the next version.
>
I booted the system with "ima_policy=tcb" policy with/without my patch.
I also removed /etc/ima/ima-policy for testing these use-cases.
(so that it wouldn't override the policy generated by boot param
"ima_policy=tcb").
I double checked the contents of the kernel policy:
#cat /sys/kernel/security/integrity/ima/policy
dont_measure fsmagic=0x9fa0
dont_measure fsmagic=0x62656572
dont_measure fsmagic=0x64626720
dont_measure fsmagic=0x1021994
dont_measure fsmagic=0x1cd1
dont_measure fsmagic=0x42494e4d
dont_measure fsmagic=0x73636673
dont_measure fsmagic=0xf97cff8c
dont_measure fsmagic=0x43415d53
dont_measure fsmagic=0x27e0eb
dont_measure fsmagic=0x63677270
dont_measure fsmagic=0x6e736673
dont_measure fsmagic=0xde5e81e4
measure func=MMAP_CHECK mask=MAY_EXEC
measure func=BPRM_CHECK mask=MAY_EXEC
measure func=FILE_CHECK mask=^MAY_READ euid=0
measure func=FILE_CHECK mask=^MAY_READ uid=0
measure func=MODULE_CHECK
measure func=FIRMWARE_CHECK
measure func=POLICY_CHECK
And then I compared the contents of the ascii_runtime_measurements with
and without my patch.
And here are my findings:
(1) Files like systemd-udevd, x2go_sessions etc. get measured multiple
times with the CONFIG_IMA_DISABLE_HTABLE=y.
They only get measured once with the config "=n".
10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng
sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd
10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng
sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd
(2) There are lot more instances of /tmp/<random> measurement records
with the CONFIG_IMA_DISABLE_HTABLE=y.
Eg,
10 33515851cfee4acbf24de9482ff018d33def1083 ima-ng
sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/oUWCVeypLR
10 9d1dc0e1e54ee2e16308a824fc5780bd21b38208 ima-ng
sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/etX8dy7qqy
10 8643a5543179b86c02d7e3e01e16b3bd2f8dbb9f ima-ng
sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/I4zTWEuyMf
10 56e9547a4ed39036d2e790cfad78b467aa979e32 ima-ng
sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/Lh5wDm6_Ep
I believe both the observations are consistent with the expected outcome
of the patch.
Please let me know if I should test any other scenario.
I will shortly post the v3 patch with updates to description and title
as you suggested.
Thanks,
Tushar
> Thanks,
> Tushar
>
>> thanks,
>>
>> Mimi
>>
On Thu, 2021-02-18 at 14:05 -0800, Tushar Sugandhi wrote:
> On 2021-02-17 12:49 p.m., Tushar Sugandhi wrote:
> > On 2021-02-17 12:39 p.m., Mimi Zohar wrote:
> >> On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote:
> >>> Thanks for the feedback Mimi.
> >>> Appreciate it.
> >>>
> >>> On 2021-02-17 7:03 a.m., Mimi Zohar wrote:
> >>>> Hi Tushar,
> >>>>
> >>>> The Subject line could be improved. Perhaps something like - "IMA:
> >>>> support for duplicate measurement records"
> >>>>
> >>> Will do.
> >>>
> >>>> On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote:
> >>>>> IMA does not measure duplicate data since TPM extend is a very
> >>>>> expensive
> >>>>> operation. However, in some cases, 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 measurements
> >>>>> on the system.
> >>>>
> >>>> This patch description is written from your specific usecase
> >>>> perspective, but it impacts file and buffer data measurements as well,
> >>>> not only critical data measurements. In all of these situations, with
> >>>> this patch a new measurement record is added/appended to the
> >>>> measurement list. Please re-write the patch description making it more
> >>>> generic.
> >>>>
> >>>> For example, I would start with something like, "IMA does not include
> >>>> duplicate file, buffer or critical data measurement records ..."
> >>>>
> >>> Agreed.
> >>> I will generalize the description further and send the v3 for review.
> >>
> >> It would be good to boot with the ima_policy=tcb policy with/without
> >> your patch and account for the different number of measurements. Are
> >> all the differences related to duplicate measurements - original file
> >> hash -> new file hash -> original file hash - similar to what you
> >> described.
> >>
> > Thanks for the ima_policy=tcb pointer.
> >
> > I tested my patch with:
> > - duplicate buffer content for "measure func=CRITICAL_DATA"
> > - and reading the same file twice with "measure func=FILE_CHECK
> > mask=MAY_READ"
> >
> > In both the above use cases, IMA is measuring the duplicate entries with
> > the patch, and not measuring the duplicate entries w/o the patch.
> >
> > I will test the "ima_policy=tcb" boot-scenario as you suggested, before
> > posting the next version.
> >
>
> I booted the system with "ima_policy=tcb" policy with/without my patch.
> I also removed /etc/ima/ima-policy for testing these use-cases.
> (so that it wouldn't override the policy generated by boot param
> "ima_policy=tcb").
>
> I double checked the contents of the kernel policy:
> #cat /sys/kernel/security/integrity/ima/policy
> dont_measure fsmagic=0x9fa0
> dont_measure fsmagic=0x62656572
> dont_measure fsmagic=0x64626720
> dont_measure fsmagic=0x1021994
> dont_measure fsmagic=0x1cd1
> dont_measure fsmagic=0x42494e4d
> dont_measure fsmagic=0x73636673
> dont_measure fsmagic=0xf97cff8c
> dont_measure fsmagic=0x43415d53
> dont_measure fsmagic=0x27e0eb
> dont_measure fsmagic=0x63677270
> dont_measure fsmagic=0x6e736673
> dont_measure fsmagic=0xde5e81e4
> measure func=MMAP_CHECK mask=MAY_EXEC
> measure func=BPRM_CHECK mask=MAY_EXEC
> measure func=FILE_CHECK mask=^MAY_READ euid=0
> measure func=FILE_CHECK mask=^MAY_READ uid=0
> measure func=MODULE_CHECK
> measure func=FIRMWARE_CHECK
> measure func=POLICY_CHECK
>
> And then I compared the contents of the ascii_runtime_measurements with
> and without my patch.
>
> And here are my findings:
>
> (1) Files like systemd-udevd, x2go_sessions etc. get measured multiple
> times with the CONFIG_IMA_DISABLE_HTABLE=y.
> They only get measured once with the config "=n".
>
> 10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng
> sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd
> 10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng
> sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd
>
> (2) There are lot more instances of /tmp/<random> measurement records
> with the CONFIG_IMA_DISABLE_HTABLE=y.
> Eg,
>
> 10 33515851cfee4acbf24de9482ff018d33def1083 ima-ng
> sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/oUWCVeypLR
> 10 9d1dc0e1e54ee2e16308a824fc5780bd21b38208 ima-ng
> sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/etX8dy7qqy
> 10 8643a5543179b86c02d7e3e01e16b3bd2f8dbb9f ima-ng
> sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/I4zTWEuyMf
> 10 56e9547a4ed39036d2e790cfad78b467aa979e32 ima-ng
> sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/Lh5wDm6_Ep
>
> I believe both the observations are consistent with the expected outcome
> of the patch.
These measurement records are not a result of the scenario described in
the patch description, but as the result of different inodes being
measured. In the first case, the measurement is most likely coming
from the initramfs, while the second measurement is after pivot root.
Without digging, I assume the second example is the file hash of an
empty file.
>
> Please let me know if I should test any other scenario.
>
> I will shortly post the v3 patch with updates to description and title
> as you suggested.
The patch description is much better, but doesn't address the duplicate
measurements without the file changing in between. Please really
compare the before and after measurement record changes, making sure
you understand the cause for all the duplicate measurement records.
Based on the results, please update the patch description
appropriately.
thanks,
Mimi