lkml.org 
[lkml]   [2020]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 0/7] IMA: Infrastructure for measurement of critical kernel data
From
Date


On 2020-11-04 4:31 p.m., Mimi Zohar wrote:
> Hi Tushar,
>
> Measuring "critical kernel data" is not a new infrastructure, simply a
> new IMA hook. Please update the above Subject line to "support for
> measuring critical kernel data".
>
Thanks a lot. Will update.
> On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote:
>> There are several kernel subsystems that contain critical data which if
>> accidentally or maliciously altered, can compromise the integrity of the
>> system. Examples of such subsystems would include LSMs like SELinux, or
>> AppArmor; or device-mapper targets like dm-crypt, dm-verity etc.
>> "critical data" in this context is kernel subsystem specific information
>> that is stored in kernel memory. Examples of critical data could be
>> kernel in-memory r/o structures, hash of the memory structures, or
>> data that represents a linux kernel subsystem state.
>
> This is a bit better, but needs to be much clearer. Please define
> "critical data", not by example, but by describing "what" critical
> kernel data is. "There are several kernel subsystems ...." is an
> example of "how" it would be used, not a definition. Without a clear
> definition it will become a dumping ground for measuring anything
> anyone wants to measure. As a result, it may be abused.
>
Good point. I will come up with a better definition.
>>
>> This patch set defines a new IMA hook namely CRITICAL_DATA, and a
>> function ima_measure_critical_data() - to measure the critical data.
>
> The name of the IMA hook is ima_measure_critical_data. This is similar
> to the LSM hooks, which are prefixed with "security_". (For a full
> list of LSM hooks, refer to lsm_hook_defs.h.)
>
Thanks for the clarification. I will update this description.
>> Kernel subsystems can use this functionality, to take advantage of IMA's
>> measuring and quoting abilities - thus ultimately enabling remote
>> attestation for the subsystem specific information stored in the kernel
>> memory.
>>
>> The functionality is generic enough to measure the data of any kernel
>> subsystem at run-time. To ensure that only data from supported sources
>> are measured, the kernel subsystem needs to be added to a compile-time
>> list of supported sources (an "allowed list of components"). IMA
>> validates the source passed to ima_measure_critical_data() against this
>> allowed list at run-time.
>
> Yes, this new feature is generic, but one of the main goals of IMA is
> to measure and attest to the integrity of the system, not to measure
> and attest to random things.
>
Ok. I will update the above paragraph accordingly.
>>
>> System administrators may want to pick and choose which kernel
>> subsystem information they would want to enable for measurements,
>> quoting, and remote attestation. To enable that, a new IMA policy is
>> introduced.
>
> ^may want to limit the critical data being measured, quoted and
> attested.
> ^ a new IMA policy condition is defined.
>
Sounds good. Will update.
>>
>> This patch set also addresses the need for the kernel subsystems to
>> measure their data before a custom IMA policy is loaded - by providing
>> a builtin IMA policy.
>
> ^for measuring kernel critical data early, before a custom IMA policy
> ...
>
Sounds good. Will update.
>>
>> And lastly, the use of the overall functionality is demonstrated by
>> measuring the kernel in-memory data for one such subsystem - SeLinux.
>
> The purpose isn't to demonstrate the "overall functionality", but to
> provide an initial caller of the new IMA hook.
>
Fair point. Will change the description accordingly.
~Tushar

> thanks,
>
> Mimi
>

\
 
 \ /
  Last update: 2020-11-12 23:19    [W:0.193 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site