Date:   Wed, 04 Nov 2020 19:31:19 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Tushar Sugandhi <tusharsu@...ux.microsoft.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

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".

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.

> 
> 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.)

> 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.

> 
> 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.

> 
> 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
...

> 
> 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.

thanks,

Mimi

Powered by blists - more mailing lists