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
