On Mon, 2026-08-17 at 12:23 +0200, Nicolai Kuntze wrote: > Hi, > > This is a design RFC, not a patch submission -- I'd like feedback on > the approach before polishing the patch series further. A working > reference implementation exists today for demonstration; details and > links below. > > Problem > > Every existing IMA hook (FILE_CHECK, MMAP_CHECK, BPRM_CHECK, > MODULE_CHECK, ...) measures once, at load time: file open, exec, > mmap, module load, or an explicit ima_measure_critical_data() call. > Nothing in IMA today re-measures an object after it's already > resident. A process's .text
A processes text segment is mapped ro and cannot change. We're looking to apply the kernel ROX guarantees to user processes, which would make it very hard even for someone with privilege to modify the text segment, but if you're looking to fix something like the copy fail cache corruption, then a strengthened ROX mechanism would be way better than trying to detect it. > or GOT can be modified in memory after load The GOT (and GOT.PLT) sections are updated by the dynamic linker *after* the binary is measured. They're also often constructed lazily by just in time symbol resolution meaning they change throughout the lifetime of the process ... therefore if you include them, practically every measurement will be different and there'll be no way to reconstruct what measurement you should have seen or relate it back to the original measurement. It is possible to do non-lazy linking and then seal the GOT read only, but that incurs a huge startup cost, so what is the actual threat model here? > (ptrace(), a kernel exploit writing through /proc/pid/mem, or > similar) without IMA ever re-examining it Those are all privileged operations, so what is the threat model you're guarding against? because if it's something like container mutations, then using dm-verity and proper ROX handling is likely a better guarantor. Regards, James
