On Fri, 2025-11-07 at 11:56 +0100, Lennart Poettering wrote: > On Fr, 07.11.25 10:44, Roberto Sassu ([email protected]) wrote: > > > On Thu, 2025-11-06 at 18:14 +0000, Tahera Fahimi wrote: > > > Prevent redundant IMA policy rules by checking for duplicates before > > > insertion. This ensures that > > > rules are not re-added when userspace is restarted (using > > > systemd-soft-reboot) without a full system > > > reboot. ima_rule_exists() detects duplicates in both temporary and active > > > rule lists. > > > > + Lennart > > > > Hi Tahera > > > > thanks for the patch! > > > > Wouldn't be better to enhance systemd-soft-reboot to not send the same > > IMA policy again? > > the soft-reboot logic doesn't load the IMA policy. It's just that > soft-reboot means we reexec PID1: the old pid1 gets replaced by the > new one. And that new PID1 then initializes as it usually would, and > loads security policies again. It currently has support for selinux > policies, ima, ipe, smack. > > These policies are supposed to *replace* whatever was loaded > before. Looking at our IMA logic, this doesn't happen right now > though, it just adds stuff:
>From a functional perspective. As far as integrity is concerned, you would probably agree that just replacing PID 1 does not mean resetting the integrity of the system to a known state (all the other processes are still running). Due to that, I think the concept of soft-reset should not be applied to the kernel. > https://github.com/systemd/systemd/blob/main/src/core/ima-setup.c > > Is there a way to replace the old IMA policy with the new, with the > current IMA userspace interface? If so, we should probably make use of No, only the IMA boot policies specified in the kernel command line can be reset (only once, and not completely, secure boot rules still persist despite user space loads a new policy). New rules are append- only. > that in systemd, and replace the policy that way. Or in other words: > under the assumption that one can flush out the old IMA policy and > replace it with a new one, I think this should be fixed in systemd, > not the kernel. (of there's no api for flushing out the old > policy/replacing it with the new, then of course we need something > like that in the kernel first). Assuming that technically it is feasible to flush the old IMA policy (except for the permanent secure boot rules). What it would be the additional value of changing the policy on the fly on the same system as before, but with a different PID 1? Regarding the duplicate IMA policy load, I guess you could probably store the digest of the currently loaded policy in the systemd state and not doing it again after soft-reboot, if the digest matches. Roberto > My understanding of IMA is kinda limited though. I just know what we > do in our codebase. > > Lennart
