linux-kernel - Re: [PATCH v5 0/7] IMA: Infrastructure for measurement of critical kernel data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a554b2d0-c59a-4ed8-12b8-5a1735cae9a4@linux.microsoft.com>
Date:   Thu, 12 Nov 2020 14:18:53 -0800
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, paul@...l-moore.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 v5 0/7] IMA: Infrastructure for measurement of critical
 kernel data



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
>