[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <016d20e1-bb8f-f1f5-c69b-6fd811126e0c@linux.microsoft.com>
Date: Fri, 23 Oct 2020 15:54:54 -0700
From: Tushar Sugandhi <tusharsu@...ux.microsoft.com>
To: Mimi Zohar <zohar@...ux.ibm.com>, stephen.smalley.work@...il.com,
casey@...aufler-ca.com, agk@...hat.com, snitzer@...hat.com,
gmazyland@...il.com
Cc: tyhicks@...ux.microsoft.com, sashal@...nel.org, jmorris@...ei.org,
nramas@...ux.microsoft.com, linux-integrity@...r.kernel.org,
selinux@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, dm-devel@...hat.com
Subject: Re: [PATCH v4 5/6] IMA: add hook to measure critical data from kernel
components
On 2020-10-22 3:35 p.m., Mimi Zohar wrote:
> Hi Tushar,
>
> On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote:
>> Currently, IMA does not provide a generic function for kernel components
>> to measure their data. A generic function provided by IMA would
>> enable various parts of the kernel with easier and faster on-boarding to
>> use IMA infrastructure, would avoid code duplication, and consistent
>> usage of IMA policy option "data_sources:=" across the kernel.
>>
>> Add a new IMA func CRITICAL_DATA and a corresponding IMA hook
>> ima_measure_critical_data() to support measuring various critical kernel
>> components. Limit the measurement to the components that are specified
>> in the IMA policy - CRITICAL_DATA+data_sources.
>>
>> Signed-off-by: Tushar Sugandhi <tusharsu@...ux.microsoft.com>
>
> Normally the new LSM or IMA hook is defined before defining a method of
> constraining that hook. Please drop 2/6 (IMA: conditionally allow
> empty rule data) and reverse the order of 4/6 and 5/6. That will
> allow each patch to update the Documentation appropriately, making the
> change self contained.
>
Sure. I will drop 2/6, and reverse the order of 4/6 and 5/6.
>> ---
>> Documentation/ABI/testing/ima_policy | 8 ++++++-
>> include/linux/ima.h | 8 +++++++
>> security/integrity/ima/ima.h | 1 +
>> security/integrity/ima/ima_api.c | 2 +-
>> security/integrity/ima/ima_main.c | 26 +++++++++++++++++++++
>> security/integrity/ima/ima_policy.c | 34 ++++++++++++++++++++++++----
>> 6 files changed, 72 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
>> index a81cf79fb255..d33bb51309fc 100644
>> --- a/Documentation/ABI/testing/ima_policy
>> +++ b/Documentation/ABI/testing/ima_policy
>> @@ -29,7 +29,7 @@ Description:
>> base: func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
>> [FIRMWARE_CHECK]
>> [KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
>> - [KEXEC_CMDLINE] [KEY_CHECK]
>> + [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
>> mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
>> [[^]MAY_EXEC]
>> fsmagic:= hex value
>> @@ -51,6 +51,8 @@ Description:
>> data_sources:= list of kernel components
>> (eg, selinux|apparmor|dm-crypt) that contain data critical
>> to the security of the kernel.
>> + Only valid when action is "measure" and func is
>> + CRITICAL_DATA.
>>
>> default policy:
>> # PROC_SUPER_MAGIC
>> @@ -128,3 +130,7 @@ Description:
>> keys added to .builtin_trusted_keys or .ima keyring:
>>
>> measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima
>> +
>> + Example of measure rule using CRITICAL_DATA to measure critical data
>> +
>> + measure func=CRITICAL_DATA data_sources=selinux|apparmor|dm-crypt
>
>
> As data sources are added, the documentation example should be updated
> to reflect the new source. Please do not include examples that don't
> yet exist.
>
Makes sense. Will do.
>
>> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
>> index 6888fc372abf..d55896f28790 100644
>> --- a/security/integrity/ima/ima_main.c
>> +++ b/security/integrity/ima/ima_main.c
>> @@ -867,6 +867,32 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
>> fdput(f);
>> }
>>
>> +/**
>> + * ima_measure_critical_data - measure critical data
>> + * @event_name: name for the given data
>> + * @event_data_source: name of the event data source
>> + * @buf: pointer to buffer containing data to measure
>> + * @buf_len: length of buffer(in bytes)
>> + * @measure_buf_hash: if set to true - will measure hash of the buf,
>> + * instead of buf
>> + *
>> + * Buffers can only be measured, not appraised.
>> + */
>
> Perhaps the reason for defining both the event_name and
> event_data_source will become clearer with an example. At this point I
> can only guess as to why both are needed (e.g. perhaps a data source
> defines multiple events).
>
Yes. Precisely. For example, in “dm-crypt” case: the data source is
“dm-crypt” and possible events are “add_target”, “post_suspend”,
"resume" etc. I will add a more detailed hook description as you
suggested below, and explain this point in it.
> While "Buffers can only be measured, not appraised" is true, it was cut
> & pasted from ima_kexec_cmdline. Measuring the kexec boot cmdline is
> self describing. Here, a larger, more detailed IMA hook description
> would be appropriate.
Will add. Thanks Mimi.
>
> thanks,
>
> Mimi
>
Powered by blists - more mailing lists