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

[Tushar Sugandhi]

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