On Wed, 2022-10-19 at 11:59 -0700, Kees Cook wrote:
> On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> > On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> > > This moves the trivial hard-coded stacking of IMA LSM hooks into the
> > > existing LSM infrastructure.
> >
> > The only thing trivial about making IMA and EVM LSMs is moving them to
> > LSM hooks. Although static files may be signed and the signatures
> > distributed with the file data through the normal distribution
> > mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
> > configuration files). For these files, both IMA and EVM may be
> > configured to maintain persistent file state stored as security xattrs
> > in the form of security.ima file hashes or security.evm HMACs. The LSM
> > flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
> > this usage, potentially preventing subsequent boots.
>
> I'm not suggesting IMA and EVM don't have specific behaviors that need to
> be correctly integrated into the LSM infrastructure. In fact, I spent a
> lot of time designing that infrastructure to be flexible enough to deal
> with these kinds of things. (e.g. plumbing "enablement", etc.) As I
> mentioned, this was more of trying to provide a head-start on the
> conversion. I don't intend to drive this -- please take whatever is
> useful from this example and use it. :) I'm happy to help construct any
> missing infrastructure needed (e.g. LSM_ORDER_LAST, etc).
>
> As for preventing subsequent boots, this is already true with other LSMs
> that save state that affects system behavior (like SELinux tags, AppArmor
> policy). IMA and EVM are not special in that regard conceptually.
> Besides, it also looks like it's already possible to boot with IMA or EVM
> disabled ("ima_appraise=off", or "evm=fix"), so there's no regression
> conceptually for having "integrity" get dropped from the lsm= list at
> boot. And if you want it not to be silent disabling, that's fine --
> just panic during initialization if "integrity" is disabled, as is
> already happening.
Being able to specify "ima_appraise=" on the boot command line requires
IMA_APPRAISE_BOOTPARAM to be configured. Even when specified, if the
system is booted with secure-boot mode enabled, it also cannot be
modified. With the ability of randomly enabling/disabling LSMs, these
protections are useless.
>
> Note that, generally speaking, LSMs have three initialization points:
> LSM init, fs_initcall, and late_initcall:
IMA initialization is deferred to late_initcall to allow the TPM to
finish initializing. It doesn't make a difference when the iint_cache
is initialized. It just needs to be prior to IMA/EVM initializiation.
>
> $ grep -R _initcall security/*/ | wc -l
> 31
>
> This, again, isn't different for IMA or EVM. The LSM infrastructure is
> about gathering and standardizing the requirements needed to run security
> hooks in a common way. The goal isn't to break IMA/EVM -- anything
> needed can be created for it. The goal is to remove _exceptions_ to the
> common hook mechanism.
>
> BTW, are there examples of how to test an IMA/EVM system? I couldn't
> find any pre-existing test images one can boot in QEMU, or instructions
> on how to create such an image, but I could have missed it.
There are specific tests in LTP, kselftests, and ima-evm-utils, but
they are incomplete.
