Re: [PATCH v4 0/6] IMA: Infrastructure for measurement of critical kernel data
Hi Mimi,
Thanks a lot for your continual engagement and
providing us valuable feedback on this work.
On 2020-10-24 8:35 p.m., Mimi Zohar wrote:
Hi Tushar,
On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote:
There are several kernel components that contain critical data which if
accidentally or maliciously altered, can compromise the security of the
kernel. Example of such components would include LSMs like SELinux, or
AppArmor; or device-mapper targets like dm-crypt, dm-verity etc.
^"the integrity of the system."
Ok. I will revisit this cover letter again, when we post the next
version of the series. We also need to update the cover letter to
include the description for new patches to be added in this series, as
per your suggestion below. {built-in policy patch (by Lakshmi) and an
example measurement patch (SeLinux by Lakshmi)}
This cover letter needs to be re-written from a higher perspective,
explaining what is meant by "critical data" (e.g. kernel subsystem
specific information only stored in kernel memory).
Many of these components do not use the capabilities provided by kernel
integrity subsystem (IMA), and thus they don't use the benefits of
extended TPM PCR quotes and ultimately the benefits of remote attestation.
True, up until recently IMA only measured files, nothing else. Why is
this paragraph needed? What new information is provided?
Here, I was attempting to describe the problem (what needs to be
solved), before proposing a solution below. But maybe it is not adding
value. I will get rid of the above paragraph in the next iteration.
This series bridges this gap, so that potential kernel components that
contain data critical to the security of the kernel could take advantage
of IMA's measuring and quoting abilities - thus ultimately enabling
remote attestation for their specific data.
Perhaps, something more along the lines, "This patch set defines a new
IMA hook named ... to measure critical data."
Will do.
System administrators may want to pick and choose which kernel
components they would want to enable for measurements, quoting, and
remote attestation. To enable that, a new IMA policy is introduced.
Reverse the order of this paragraph and the following one, describing
the new feature and only afterwards explaining how it may be
constrained.
Makes total sense. Will do.
And lastly, the functionality is exposed through a function
ima_measure_critical_data(). The functionality is generic enough to
measure the data of any kernel component at run-time. To ensure that
only data from supported sources are measured, the kernel component
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.
This patch set must include at least one example of measuring critical
data, before it can be upstreamed. Tushar, please coordinate with
Lakshmi and Raphael.
Yes. I am coordinating with Lakshmi/Raphael on including one of the
examples. (SeLinux as per your feedback)
BTW, we also have one more data source (dm-crypt) currently in review,
that uses critical data measurement infrastructure to measure its kernel
in-memory data.
https://patchwork.kernel.org/patch/11844817/
Thanks again for all the help and support with the patches.
~Tushar
thanks,
Mimi
Re: [PATCH v4 0/6] IMA: Infrastructure for measurement of critical kernel data
Hi Tushar, On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote: > There are several kernel components that contain critical data which if > accidentally or maliciously altered, can compromise the security of the > kernel. Example of such components would include LSMs like SELinux, or > AppArmor; or device-mapper targets like dm-crypt, dm-verity etc. ^"the integrity of the system." This cover letter needs to be re-written from a higher perspective, explaining what is meant by "critical data" (e.g. kernel subsystem specific information only stored in kernel memory). > > Many of these components do not use the capabilities provided by kernel > integrity subsystem (IMA), and thus they don't use the benefits of > extended TPM PCR quotes and ultimately the benefits of remote attestation. True, up until recently IMA only measured files, nothing else. Why is this paragraph needed? What new information is provided? > This series bridges this gap, so that potential kernel components that > contain data critical to the security of the kernel could take advantage > of IMA's measuring and quoting abilities - thus ultimately enabling > remote attestation for their specific data. Perhaps, something more along the lines, "This patch set defines a new IMA hook named ... to measure critical data." > > System administrators may want to pick and choose which kernel > components they would want to enable for measurements, quoting, and > remote attestation. To enable that, a new IMA policy is introduced. Reverse the order of this paragraph and the following one, describing the new feature and only afterwards explaining how it may be constrained. > > And lastly, the functionality is exposed through a function > ima_measure_critical_data(). The functionality is generic enough to > measure the data of any kernel component at run-time. To ensure that > only data from supported sources are measured, the kernel component > 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. This patch set must include at least one example of measuring critical data, before it can be upstreamed. Tushar, please coordinate with Lakshmi and Raphael. thanks, Mimi
[PATCH v4 0/6] IMA: Infrastructure for measurement of critical kernel data
There are several kernel components that contain critical data which if
accidentally or maliciously altered, can compromise the security of the
kernel. Example of such components would include LSMs like SELinux, or
AppArmor; or device-mapper targets like dm-crypt, dm-verity etc.
Many of these components do not use the capabilities provided by kernel
integrity subsystem (IMA), and thus they don't use the benefits of
extended TPM PCR quotes and ultimately the benefits of remote attestation.
This series bridges this gap, so that potential kernel components that
contain data critical to the security of the kernel could take advantage
of IMA's measuring and quoting abilities - thus ultimately enabling
remote attestation for their specific data.
System administrators may want to pick and choose which kernel
components they would want to enable for measurements, quoting, and
remote attestation. To enable that, a new IMA policy is introduced.
And lastly, the functionality is exposed through a function
ima_measure_critical_data(). The functionality is generic enough to
measure the data of any kernel component at run-time. To ensure that
only data from supported sources are measured, the kernel component
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.
This series is based on the following repo/branch:
repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
branch: next-integrity
commit aa662fc04f5b ("ima: Fix NULL pointer dereference in ima_file_hash")
Change Log v4:
Incorporated feedback from Mimi on v3.
- Split patch #1 into two patches to move introduction of bool
allow_empty_opt_list into the 2nd patch.
- Reverted return type of process_buffer_measurement() from int to void
which got rid of patch #2 from the v3 of the series.
- Renamed the policy "critical_kernel_data_sources" to "data_sources".
- Updated process_buffer_measurement() to avoid code and variable
duplication in the if(measure_buf_hash) block.
- Changed return type of ima_measure_critical_data() from int to void.
- Updated patch description for patch #3 and #4 as per Mimi's feedback.
Change Log v3:
Incorporated feedback from Mimi on v2.
- Renamed the policy "data_sources" to
"critical_kernel_data_sources".
- Added "critical_kernel_data_sources" description in
Documentation/ima-policy.
- Split CRITICAL_DATA + critical_kernel_data_sources into two separate
patches.
- Merged hook ima_measure_critical_data() + CRITICAL_DATA into a single
patch.
- Added functionality to validate data sources before measurement.
Change Log v2:
- Reverted the unnecessary indentations in existing #define.
- Updated the description to replace the word 'enlightened' with
'supported'.
- Reverted the unnecessary rename of attribute size to buf_len.
- Introduced a boolean parameter measure_buf_hash as per community
feedback to support measuring hash of the buffer, instead of the
buffer itself.
Tushar Sugandhi (6):
IMA: generalize keyring specific measurement constructs
IMA: conditionally allow empty rule data
IMA: update process_buffer_measurement to measure buffer hash
IMA: add policy to measure critical data from kernel components
IMA: add hook to measure critical data from kernel components
IMA: validate supported kernel data sources before measurement
Documentation/ABI/testing/ima_policy | 11 +-
include/linux/ima.h | 8 ++
security/integrity/ima/ima.h | 37 ++-
security/integrity/ima/ima_api.c | 8 +-
security/integrity/ima/ima_appraise.c| 2 +-
security/integrity/ima/ima_asymmetric_keys.c | 2 +-
security/integrity/ima/ima_main.c| 61 ++-
security/integrity/ima/ima_policy.c | 101 +++
security/integrity/ima/ima_queue_keys.c | 3 +-
9 files changed, 196 insertions(+), 37 deletions(-)
--
2.17.1
