| Message ID | 20210217024649.23405-1-tusharsu@linux.microsoft.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] IMA: support for duplicate data measurement | expand |
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 <tusharsu@linux.microsoft.com>
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 <tusharsu@linux.microsoft.com>
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
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 >
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
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;
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 <tusharsu@linux.microsoft.com> --- 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(-)