Message-ID: <CAEjxPJ4woNFU+FvmP72sjcfxotrjS4VFWL5ECS9ensKYUpF84Q@mail.gmail.com>
Date:   Tue, 8 Sep 2020 08:35:02 -0400
From:   Stephen Smalley <stephen.smalley.work@...il.com>
To:     Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>, Paul Moore <paul@...l-moore.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Tyler Hicks <tyhicks@...ux.microsoft.com>,
        tusharsu@...ux.microsoft.com, Sasha Levin <sashal@...nel.org>,
        James Morris <jmorris@...ei.org>,
        linux-integrity@...r.kernel.org,
        SElinux list <selinux@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] SELinux: Measure state and hash of policy using IMA

On Tue, Sep 8, 2020 at 8:28 AM Stephen Smalley
<stephen.smalley.work@...il.com> wrote:
>
> On Mon, Sep 7, 2020 at 5:39 PM Lakshmi Ramasubramanian
> <nramas@...ux.microsoft.com> wrote:
> >
> > Critical data structures of security modules are currently not measured.
> > Therefore an attestation service, for instance, would not be able to
> > attest whether the security modules are always operating with the policies
> > and configuration that the system administrator had setup. The policies
> > and configuration for the security modules could be tampered with by
> > rogue user mode agents or modified through some inadvertent actions on
> > the system. Measuring such critical data would enable an attestation
> > service to reliably assess the security configuration of the system.
> >
> > SELinux configuration and policy are some of the critical data for this
> > security module that needs to be measured. This measurement can be used
> > by an attestation service, for instance, to verify if the configuration
> > and policies have been setup correctly and that they haven't been tampered
> > with at runtime.
> >
> > Measure SELinux configuration, policy capabilities settings, and the hash
> > of the loaded policy by calling the IMA hook ima_measure_critical_data().
> > Since the size of the loaded policy can be quite large, hash of the policy
> > is measured instead of the entire policy to avoid bloating the IMA log.
> >
> > Enable early boot measurement for SELinux in IMA since SELinux
> > initializes its state and policy before custom IMA policy is loaded.
> >
> > Sample measurement of SELinux state and hash of the policy:
> >
> > 10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state-1595389364:287899386 696e697469616c697a65643d313b656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574776f726b5f706565725f636f6e74726f6c733d313b6f70656e5f7065726d733d313b657874656e6465645f736f636b65745f636c6173733d313b616c776179735f636865636b5f6e6574776f726b3d303b6367726f75705f7365636c6162656c3d313b6e6e705f6e6f737569645f7472616e736974696f6e3d313b67656e66735f7365636c6162656c5f73796d6c696e6b733d303
> > 10 9e81...0857 ima-buf sha256:4941...68fc selinux-policy-hash-1597335667:462051628 8d1d...1834
> >
> > To verify the measurement check the following:
> >
> > Execute the following command to extract the measured data
> > from the IMA log for SELinux configuration (selinux-state).
> >
> >   grep -m 1 "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 | xxd -r -p
> >
> > The output should be the list of key-value pairs. For example,
> >  initialized=1;enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
> >
> > To verify the measured data with the current SELinux state:
> >
> >  => enabled should be set to 1 if /sys/fs/selinux folder exists,
> >     0 otherwise
> >
> > For other entries, compare the integer value in the files
> >  => /sys/fs/selinux/enforce
> >  => /sys/fs/selinux/checkreqprot
> > And, each of the policy capabilities files under
> >  => /sys/fs/selinux/policy_capabilities
> >
> > For selinux-policy-hash, the hash of SELinux policy is included
> > in the IMA log entry.
> >
> > To verify the measured data with the current SELinux policy run
> > the following commands and verify the output hash values match.
> >
> >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> >
> >   grep -m 1 "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6
> >
> > This patch is based on commit 66ccd2560aff ("selinux: simplify away security_policydb_len()")
> > in "next" branch in https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
> >
> > This patch is dependent on the following patch series and must be
> > applied in the given order:
> >         https://patchwork.kernel.org/patch/11709527/
> >         https://patchwork.kernel.org/patch/11730193/
> >         https://patchwork.kernel.org/patch/11730757/
> >
> > Signed-off-by: Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
> > Suggested-by: Stephen Smalley <stephen.smalley.work@...il.com>
> > ---
> >
> > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > index 953314d145bb..9bf0f65d720b 100644
> > --- a/security/integrity/ima/Kconfig
> > +++ b/security/integrity/ima/Kconfig
> > @@ -324,8 +324,7 @@ config IMA_MEASURE_ASYMMETRIC_KEYS
> >
> >  config IMA_QUEUE_EARLY_BOOT_DATA
> >         bool
> > -       depends on IMA_MEASURE_ASYMMETRIC_KEYS
> > -       depends on SYSTEM_TRUSTED_KEYRING
> > +       depends on (IMA_MEASURE_ASYMMETRIC_KEYS && SYSTEM_TRUSTED_KEYRING) || SECURITY_SELINUX
> >         default y
>
> I don't see why this is necessary or desirable.  We should avoid
> leaking dependencies on a single security module into other
> subsystems.
> It might not yet fully support other security modules but we shouldn't
> preclude adding that in the future.
> Up to the IMA maintainer but I would recommend dropping this part.

Sorry, I misread this part; it doesn't make IMA depend on SELinux it
just allows enabling this early boot data feature if SELinux is
enabled since SELinux is a user of it.  Still, it seems unfortunate to
have to explicitly enumerate each consumer of this facility here
whenever a new one is introduced.  Is there a reason for doing so and
not just allowing it to be enabled as long as the things on which it
depends are enabled (i.e. not based on its consumers)?

Powered by blists - more mailing lists