Re: [PATCH v4 04/11] ima: Move ima_reset_appraise_flags() call to post hooks

[Mimi Zohar]

On Tue, 2021-04-27 at 09:25 +0000, Roberto Sassu wrote:
> > From: Mimi Zohar [mailto:zohar@xxxxxxxxxxxxx]
> > Sent: Monday, April 26, 2021 9:49 PM
> > On Fri, 2021-03-05 at 09:30 -0800, Casey Schaufler wrote:

> > > However ...
> > >
> > > The special casing of IMA and EVM in security.c is getting out of
> > > hand, and appears to be unnecessary. By my count there are 9 IMA
> > > hooks and 5 EVM hooks that have been hard coded. Adding this IMA
> > > hook makes 10. It would be really easy to register IMA and EVM as
> > > security modules. That would remove the dependency they currently
> > > have on security sub-system approval for changes like this one.
> > > I know there has been resistance to "IMA as an LSM" in the past,
> > > but it's pretty hard to see how it wouldn't be a win.

It sholdn't be one way.  Are you willing to also make the existing
IMA/EVM hooks that are not currently security hooks, security hooks
too?   And accept any new IMA/EVM hooks would result in new security
hooks?  Are you also willing to add dependency tracking between LSMs?

> > 
> > Somehow I missed the new "lsm=" boot command line option, which
> > dynamically allows enabling/disabling LSMs, being upstreamed.  This
> > would be one of the reasons for not making IMA/EVM full LSMs.
> 
> Hi Mimi
> 
> one could argue why IMA/EVM should receive a special
> treatment. I understand that this was a necessity without
> LSM stacking. Now that LSM stacking is available, I don't
> see any valid reason why IMA/EVM should not be managed
> by the LSM infrastructure.
> 
> > Both IMA and EVM file data/metadata is persistent across boots.  If
> > either one or the other is not enabled the file data hash or file
> > metadata HMAC will not properly be updated, potentially preventing the
> > system from booting when re-enabled.  Re-enabling IMA and EVM would
> > require "fixing" the mutable file data hash and HMAC, without any
> > knowledge of what the "fixed" values should be.  Dave Safford referred
> > to this as "blessing" the newly calculated values.
> 
> IMA/EVM can be easily disabled in other ways, for example
> by moving the IMA policy or the EVM keys elsewhere.

Dynamically disabling IMA/EVM is very different than removing keys and
preventing the system from booting.  Restoring the keys should result
in being able to re-boot the system.  Re-enabling IMA/EVM, requires re-
labeling the filesystem in "fix" mode, which "blesses" any changes made
when IMA/EVM were not enabled.

> Also other LSMs rely on a dynamic and persistent state
> (for example for file transitions in SELinux), which cannot be
> trusted anymore if LSMs are even temporarily disabled.

Your argument is because this is a problem for SELinux, make it also a
problem for IMA/EVM too?!   ("Two wrongs make a right")

> If IMA/EVM have to be enabled to prevent misconfiguration,
> I think the same can be achieved if they are full LSMs, for
> example by preventing that the list of enabled LSMs changes
> at run-time.

That ship sailed when "security=" was deprecated in favor of "lsm="
support, which dynamically enables/disables LSMs at runtime.

Mimi