> From: Mimi Zohar [mailto:zohar@xxxxxxxxxxxxx] > Sent: Tuesday, April 27, 2021 5:35 PM > 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? I already have a preliminary branch where IMA/EVM are full LSMs. Indeed, the biggest problem would be to have the new hooks accepted. I can send the patch set for evaluation to see what people think. > > > 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. Uhm, I thought that if you move the HMAC key for example and you boot the system, you invalidate all files that change, because the HMAC is not updated. > > 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") To me it seems reasonable to give the ability to people to disable the LSMs if they want to do so, and at the same time to try to prevent accidental disable when the LSMs should be enabled. > > 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. Maybe this possibility can be disabled with a new kernel option. I will think a more concrete solution. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Li Jian, Shi Yanli
