From: Tushar Sugandhi <tusharsu@linux.microsoft.com> To: Mimi Zohar <zohar@linux.ibm.com>, stephen.smalley.work@gmail.com, casey@schaufler-ca.com, agk@redhat.com, snitzer@redhat.com, gmazyland@gmail.com, paul@paul-moore.com Cc: tyhicks@linux.microsoft.com, sashal@kernel.org, jmorris@namei.org, nramas@linux.microsoft.com, linux-integrity@vger.kernel.org, selinux@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com Subject: Re: [PATCH v9 5/8] IMA: limit critical data measurement based on a label Date: Tue, 5 Jan 2021 12:28:19 -0800 [thread overview] Message-ID: <2c1d83b6-e344-28ea-e387-01a0febbe391@linux.microsoft.com> (raw) In-Reply-To: <56db41c08d625b8143454a2e0aaaef3ea2927442.camel@linux.ibm.com> On 2020-12-24 6:29 a.m., Mimi Zohar wrote: > Hi Tushar, > > On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote: >> System administrators should be able to limit which kernel subsystems >> they want to measure the critical data for. To enable that, an IMA policy >> condition to choose specific kernel subsystems is needed. This policy >> condition would constrain the measurement of the critical data based on >> a label for the given subsystems. > > Restricting which kernel integrity critical data is measured is not > only of interest to system administrators. Why single them out? > system administrators are usually responsible for system policies/configurations.They own modifications in the config files like ima-policy. That's why we wanted to address them to begin with. But you are correct. This is not only of interest to sysadmins. I will make the description more generic. > Limiting which critical data is measured is based on a label, making it > flexible. In your use case scenario, you're grouping the label based > on kernel subsystem, but is that really necessary? In the broader > picture, there could be cross subsystem critical data being measured > based on a single label. > > Please think about the broader picture and re-write the patch > descirption more generically. > Makes sense. Will make the patch description more generic. >> >> Add a new IMA policy condition - "data_source:=" to the IMA func > > What is with "add"? You're "adding support for" or "defining" a new > policy condition. Remove the single hyphen, as explained in 3/8. > > Please replace "data_source" with something more generic (e.g. label). > Sounds good. Would you prefer "label" or something else like "data_label"? In the policy file the "label" looks logical and more generic than "data_label". measure func=CRITICAL_DATA label=selinux For the time being, I will stick with "label", please let me know if you prefer something else. Thanks, Tushar > thanks, > > Mimi > >> CRITICAL_DATA to allow measurement of various kernel subsystems. This >> policy condition would enable the system administrators to restrict the >> measurement to the labels listed in "data_source:=". >> >> Limit the measurement to the labels that are specified in the IMA >> policy - CRITICAL_DATA+"data_source:=". If "data_sources:=" is not >> provided with the func CRITICAL_DATA, the data from all the >> supported kernel subsystems is measured. >> >> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
WARNING: multiple messages have this Message-ID (diff)
From: Tushar Sugandhi <tusharsu@linux.microsoft.com> To: Mimi Zohar <zohar@linux.ibm.com>, stephen.smalley.work@gmail.com, casey@schaufler-ca.com, agk@redhat.com, snitzer@redhat.com, gmazyland@gmail.com, paul@paul-moore.com Cc: sashal@kernel.org, dm-devel@redhat.com, selinux@vger.kernel.org, jmorris@namei.org, linux-kernel@vger.kernel.org, nramas@linux.microsoft.com, linux-security-module@vger.kernel.org, tyhicks@linux.microsoft.com, linux-integrity@vger.kernel.org Subject: Re: [dm-devel] [PATCH v9 5/8] IMA: limit critical data measurement based on a label Date: Tue, 5 Jan 2021 12:28:19 -0800 [thread overview] Message-ID: <2c1d83b6-e344-28ea-e387-01a0febbe391@linux.microsoft.com> (raw) In-Reply-To: <56db41c08d625b8143454a2e0aaaef3ea2927442.camel@linux.ibm.com> On 2020-12-24 6:29 a.m., Mimi Zohar wrote: > Hi Tushar, > > On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote: >> System administrators should be able to limit which kernel subsystems >> they want to measure the critical data for. To enable that, an IMA policy >> condition to choose specific kernel subsystems is needed. This policy >> condition would constrain the measurement of the critical data based on >> a label for the given subsystems. > > Restricting which kernel integrity critical data is measured is not > only of interest to system administrators. Why single them out? > system administrators are usually responsible for system policies/configurations.They own modifications in the config files like ima-policy. That's why we wanted to address them to begin with. But you are correct. This is not only of interest to sysadmins. I will make the description more generic. > Limiting which critical data is measured is based on a label, making it > flexible. In your use case scenario, you're grouping the label based > on kernel subsystem, but is that really necessary? In the broader > picture, there could be cross subsystem critical data being measured > based on a single label. > > Please think about the broader picture and re-write the patch > descirption more generically. > Makes sense. Will make the patch description more generic. >> >> Add a new IMA policy condition - "data_source:=" to the IMA func > > What is with "add"? You're "adding support for" or "defining" a new > policy condition. Remove the single hyphen, as explained in 3/8. > > Please replace "data_source" with something more generic (e.g. label). > Sounds good. Would you prefer "label" or something else like "data_label"? In the policy file the "label" looks logical and more generic than "data_label". measure func=CRITICAL_DATA label=selinux For the time being, I will stick with "label", please let me know if you prefer something else. Thanks, Tushar > thanks, > > Mimi > >> CRITICAL_DATA to allow measurement of various kernel subsystems. This >> policy condition would enable the system administrators to restrict the >> measurement to the labels listed in "data_source:=". >> >> Limit the measurement to the labels that are specified in the IMA >> policy - CRITICAL_DATA+"data_source:=". If "data_sources:=" is not >> provided with the func CRITICAL_DATA, the data from all the >> supported kernel subsystems is measured. >> >> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com> -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-01-05 20:29 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-12 18:02 [PATCH v9 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 1/8] IMA: generalize keyring specific measurement constructs Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-24 13:06 ` Mimi Zohar 2020-12-24 13:06 ` [dm-devel] " Mimi Zohar 2021-01-05 18:48 ` Tushar Sugandhi 2021-01-05 18:48 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 2/8] IMA: add support to measure buffer data hash Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-24 0:03 ` Mimi Zohar 2020-12-24 0:03 ` [dm-devel] " Mimi Zohar 2021-01-05 18:53 ` Tushar Sugandhi 2021-01-05 18:53 ` [dm-devel] " Tushar Sugandhi 2021-01-06 5:00 ` Tushar Sugandhi 2021-01-06 5:00 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 3/8] IMA: define a hook to measure kernel integrity critical data Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-24 13:04 ` Mimi Zohar 2020-12-24 13:04 ` [dm-devel] " Mimi Zohar 2021-01-05 20:01 ` Tushar Sugandhi 2021-01-05 20:01 ` [dm-devel] " Tushar Sugandhi 2021-01-05 20:16 ` Mimi Zohar 2021-01-05 20:16 ` [dm-devel] " Mimi Zohar 2021-01-05 20:19 ` Tushar Sugandhi 2021-01-05 20:19 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 4/8] IMA: add policy rule to measure " Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-12 19:20 ` Tyler Hicks 2020-12-12 19:20 ` [dm-devel] " Tyler Hicks 2020-12-13 1:21 ` Tushar Sugandhi 2020-12-13 1:21 ` [dm-devel] " Tushar Sugandhi 2020-12-24 13:48 ` Mimi Zohar 2020-12-24 13:48 ` [dm-devel] " Mimi Zohar 2021-01-05 20:12 ` Tushar Sugandhi 2021-01-05 20:12 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 5/8] IMA: limit critical data measurement based on a label Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-12 19:20 ` Tyler Hicks 2020-12-12 19:20 ` [dm-devel] " Tyler Hicks 2020-12-13 1:21 ` Tushar Sugandhi 2020-12-13 1:21 ` [dm-devel] " Tushar Sugandhi 2020-12-24 14:29 ` Mimi Zohar 2020-12-24 14:29 ` [dm-devel] " Mimi Zohar 2021-01-05 20:28 ` Tushar Sugandhi [this message] 2021-01-05 20:28 ` Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 6/8] IMA: extend critical data hook to limit the " Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 7/8] IMA: define a builtin critical data measurement policy Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-24 14:41 ` Mimi Zohar 2020-12-24 14:41 ` [dm-devel] " Mimi Zohar 2021-01-05 20:30 ` Tushar Sugandhi 2021-01-05 20:30 ` [dm-devel] " Tushar Sugandhi 2020-12-12 18:02 ` [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook Tushar Sugandhi 2020-12-12 18:02 ` [dm-devel] " Tushar Sugandhi 2020-12-23 21:10 ` Paul Moore 2020-12-23 21:10 ` [dm-devel] " Paul Moore 2021-01-04 23:30 ` Lakshmi Ramasubramanian 2021-01-04 23:30 ` [dm-devel] " Lakshmi Ramasubramanian 2021-01-05 2:13 ` Paul Moore 2021-01-05 2:13 ` [dm-devel] " Paul Moore 2021-01-05 5:24 ` Lakshmi Ramasubramanian 2021-01-05 5:24 ` [dm-devel] " Lakshmi Ramasubramanian
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2c1d83b6-e344-28ea-e387-01a0febbe391@linux.microsoft.com \ --to=tusharsu@linux.microsoft.com \ --cc=agk@redhat.com \ --cc=casey@schaufler-ca.com \ --cc=dm-devel@redhat.com \ --cc=gmazyland@gmail.com \ --cc=jmorris@namei.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=nramas@linux.microsoft.com \ --cc=paul@paul-moore.com \ --cc=sashal@kernel.org \ --cc=selinux@vger.kernel.org \ --cc=snitzer@redhat.com \ --cc=stephen.smalley.work@gmail.com \ --cc=tyhicks@linux.microsoft.com \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.