lkml.org 
[lkml]   [2020]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v4 5/6] IMA: add hook to measure critical data from kernel components
    From
    Date
    Hi Tushar,

    On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote:
    > Currently, IMA does not provide a generic function for kernel components
    > to measure their data. A generic function provided by IMA would
    > enable various parts of the kernel with easier and faster on-boarding to
    > use IMA infrastructure, would avoid code duplication, and consistent
    > usage of IMA policy option "data_sources:=" across the kernel.
    >
    > Add a new IMA func CRITICAL_DATA and a corresponding IMA hook
    > ima_measure_critical_data() to support measuring various critical kernel
    > components. Limit the measurement to the components that are specified
    > in the IMA policy - CRITICAL_DATA+data_sources.
    >
    > Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>

    Normally the new LSM or IMA hook is defined before defining a method of
    constraining that hook. Please drop 2/6 (IMA: conditionally allow
    empty rule data) and reverse the order of 4/6 and 5/6. That will
    allow each patch to update the Documentation appropriately, making the
    change self contained.

    > ---
    > Documentation/ABI/testing/ima_policy | 8 ++++++-
    > include/linux/ima.h | 8 +++++++
    > security/integrity/ima/ima.h | 1 +
    > security/integrity/ima/ima_api.c | 2 +-
    > security/integrity/ima/ima_main.c | 26 +++++++++++++++++++++
    > security/integrity/ima/ima_policy.c | 34 ++++++++++++++++++++++++----
    > 6 files changed, 72 insertions(+), 7 deletions(-)
    >
    > diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
    > index a81cf79fb255..d33bb51309fc 100644
    > --- a/Documentation/ABI/testing/ima_policy
    > +++ b/Documentation/ABI/testing/ima_policy
    > @@ -29,7 +29,7 @@ Description:
    > base: func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
    > [FIRMWARE_CHECK]
    > [KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
    > - [KEXEC_CMDLINE] [KEY_CHECK]
    > + [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
    > mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
    > [[^]MAY_EXEC]
    > fsmagic:= hex value
    > @@ -51,6 +51,8 @@ Description:
    > data_sources:= list of kernel components
    > (eg, selinux|apparmor|dm-crypt) that contain data critical
    > to the security of the kernel.
    > + Only valid when action is "measure" and func is
    > + CRITICAL_DATA.
    >
    > default policy:
    > # PROC_SUPER_MAGIC
    > @@ -128,3 +130,7 @@ Description:
    > keys added to .builtin_trusted_keys or .ima keyring:
    >
    > measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima
    > +
    > + Example of measure rule using CRITICAL_DATA to measure critical data
    > +
    > + measure func=CRITICAL_DATA data_sources=selinux|apparmor|dm-crypt


    As data sources are added, the documentation example should be updated
    to reflect the new source. Please do not include examples that don't
    yet exist.


    > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
    > index 6888fc372abf..d55896f28790 100644
    > --- a/security/integrity/ima/ima_main.c
    > +++ b/security/integrity/ima/ima_main.c
    > @@ -867,6 +867,32 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
    > fdput(f);
    > }
    >
    > +/**
    > + * ima_measure_critical_data - measure critical data
    > + * @event_name: name for the given data
    > + * @event_data_source: name of the event data source
    > + * @buf: pointer to buffer containing data to measure
    > + * @buf_len: length of buffer(in bytes)
    > + * @measure_buf_hash: if set to true - will measure hash of the buf,
    > + * instead of buf
    > + *
    > + * Buffers can only be measured, not appraised.
    > + */

    Perhaps the reason for defining both the event_name and
    event_data_source will become clearer with an example. At this point I
    can only guess as to why both are needed (e.g. perhaps a data source
    defines multiple events).

    While "Buffers can only be measured, not appraised" is true, it was cut
    & pasted from ima_kexec_cmdline. Measuring the kexec boot cmdline is
    self describing. Here, a larger, more detailed IMA hook description
    would be appropriate.

    thanks,

    Mimi

    \
     
     \ /
      Last update: 2020-10-23 00:36    [W:3.520 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site