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 v5 5/7] IMA: validate supported kernel data sources before measurement
Date: Thu, 12 Nov 2020 14:09:28 -0800 [thread overview]
Message-ID: <5826d3df-c263-f6c8-cac0-094b3c5a9395@linux.microsoft.com> (raw)
In-Reply-To: <bef97a69db37d358db21668b179fd8821430b1b4.camel@linux.ibm.com>
On 2020-11-06 6:01 a.m., Mimi Zohar wrote:
> Hi Tushar,
>
> On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote:
>> Currently, IMA does not restrict random data sources from measuring
>> their data using ima_measure_critical_data(). Any kernel data source can
>> call the function, and it's data will get measured as long as the input
>> event_data_source is part of the IMA policy - CRITICAL_DATA+data_sources.
>>
>> To ensure that only data from supported sources are measured, the kernel
>> subsystem name needs to be added to a compile-time list of supported
>> sources (an "allowed list of components"). IMA then validates the input
>> parameter - "event_data_source" passed to ima_measure_critical_data()
>> against this allowed list at run-time.
>>
>> This compile-time list must be updated when kernel subsystems are
>> updated to measure their data using IMA.
>>
>> Provide an infrastructure for kernel data sources to be added to
>> IMA's supported data sources list at compile-time. Update
>> ima_measure_critical_data() to validate, at run-time, that the data
>> source is supported before measuring the data coming from that source.
>
> For those interested in limiting which critical data to measure, the
> "data sources" IMA policy rule option already does that. Why is this
> needed?
>
> thanks,
>
> Mimi
>
This wasn’t part of the initial series. And I wasn’t convinced if it was
really needed. :) I added it based on the feedback in v2 of this
series. (pasted below for reference[1]).
Maybe I misunderstood your feedback at that time.
*Question*
Could you please let me know if you want us to remove this patch?
[1] From v2 of this series:
https://patchwork.kernel.org/project/linux-integrity/patch/20200821182107.5328-3-tusharsu@linux.microsoft.com/
>>>> "keyrings=" isn't bounded because keyrings can be created by
userspace.
>>>> Perhaps keyring names has a minimum/maximum length. IMA isn't
>>>> measuring userspace construsts. Shouldn't the list of critical data
>>>> being measured be bounded and verified?
>>> The comment is not entirely clear.
>>> Do you mean there should be some sort of allow_list in IMA, against
>>> which the values in "data_sources=" should be vetted? And if the
>>> value is present in the IMA allow_list, then only the measurements for
>>> that data source are allowed?
>>>
>>> Or do you mean something else?
>>
>> Yes, something along those lines. Does the list of critical data need
>> to be vetted? And if so, against what?
> I am thinking of having an enum and string array - just like ima_hooks
> and ima_hooks_measure_str in ima.h.
> And any new kernel component that would support generic IMA measurements
> in future would have to add itself to the enum/array.
> And the param *event_data_source in ima_measure_critical_data() will be
> vetted against the above enum/string array.
>
> I will implement it in the next iteration, and hopefully the vetting
> workflow will be more clear.
>
> ~Tushar
>>
>> Mimi
next prev parent reply other threads:[~2020-11-12 22:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-01 22:26 [PATCH v5 0/7] IMA: Infrastructure for measurement of critical kernel data Tushar Sugandhi
2020-11-01 22:26 ` [PATCH v5 1/7] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
2020-11-01 22:26 ` [PATCH v5 2/7] IMA: update process_buffer_measurement to measure buffer hash Tushar Sugandhi
2020-11-05 14:30 ` Mimi Zohar
2020-11-12 21:47 ` Tushar Sugandhi
2020-11-12 22:19 ` Mimi Zohar
2020-11-12 23:16 ` Tushar Sugandhi
2020-11-06 12:11 ` Mimi Zohar
2020-11-12 21:48 ` Tushar Sugandhi
2020-11-01 22:26 ` [PATCH v5 3/7] IMA: add hook to measure critical data Tushar Sugandhi
2020-11-06 13:24 ` Mimi Zohar
2020-11-12 21:57 ` Tushar Sugandhi
2020-11-12 23:56 ` Mimi Zohar
2020-11-13 17:23 ` Tushar Sugandhi
2020-11-01 22:26 ` [PATCH v5 4/7] IMA: add policy " Tushar Sugandhi
2020-11-06 13:43 ` Mimi Zohar
2020-11-12 22:02 ` Tushar Sugandhi
2020-11-01 22:26 ` [PATCH v5 5/7] IMA: validate supported kernel data sources before measurement Tushar Sugandhi
2020-11-06 14:01 ` Mimi Zohar
2020-11-12 22:09 ` Tushar Sugandhi [this message]
2020-11-13 0:06 ` Mimi Zohar
2020-11-01 22:26 ` [PATCH v5 6/7] IMA: add critical_data to the built-in policy rules Tushar Sugandhi
2020-11-06 15:24 ` Mimi Zohar
2020-11-06 15:37 ` Lakshmi Ramasubramanian
2020-11-06 23:51 ` Lakshmi Ramasubramanian
2020-11-08 15:46 ` Mimi Zohar
2020-11-09 17:24 ` Lakshmi Ramasubramanian
2020-11-01 22:26 ` [PATCH v5 7/7] selinux: measure state and hash of the policy using IMA Tushar Sugandhi
2020-11-06 15:47 ` Mimi Zohar
2020-11-05 0:31 ` [PATCH v5 0/7] IMA: Infrastructure for measurement of critical kernel data Mimi Zohar
2020-11-12 22:18 ` Tushar Sugandhi
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=5826d3df-c263-f6c8-cac0-094b3c5a9395@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®