> On Thu, 2025-02-20 at 22:43 +0100, Petr Vorel wrote: > > > On Thu, 2025-02-20 at 15:22 -0500, Mimi Zohar wrote: > > > > On Thu, 2025-02-20 at 20:13 +0100, Petr Vorel wrote: > > > > > > On Thu, 2025-02-20 at 19:16 +0100, Petr Vorel wrote: > > > > > > > Hi Mimi,
> > > > > > > > Kernel patch "ima: limit the number of ToMToU integrity > > > > > > > > violations" > > > > > > > > prevents superfluous ToMToU violations. Add corresponding LTP > > > > > > > > tests. > > > > > > > > Link: > > > > > > > > https://lore.kernel.org/linux-integrity/20250219162131.416719-3-zo...@linux.ibm.com/ > > > > > > > > Signed-off-by: Mimi Zohar <zo...@linux.ibm.com> > > > > > > > Unfortunately tests fail on both mainline kernel and kernel with > > > > > > > your patches. > > > > > > The new LTP IMA violations patches should fail without the > > > > > > associated kernel > > > > > > patches. > > > > > > > Any hint what could be wrong? > > > > > > Of course it's dependent on the IMA policy. The tests assume being > > > > > > booted with > > > > > > the > > > > > > IMA > > > > > > TCB measurement policy or similar policy being loaded. Can you > > > > > > share the IMA > > > > > > policy? > > > > > > e.g. cat /sys/kernel/security/ima/policy > > > > > > thanks, > > > > > > Mimi > > > > > Now testing on kernel *with* your patches. First run always fails, > > > > > regardless > > > > > whether using ima_policy=tcb or > > > > > /opt/ltp/testcases/data/ima_violations/violations.policy). > > > > > Kind regards, > > > > > Petr > > > > I'm not seeing that on my test machine. Could there be other things > > > > running on your > > > > system causing violations. In anycase, your original test was less > > > > exacting. > > > > Similarly, > > > > instead of "-eq", try using "-qe" in the following test and removing > > > > the subsequent > > > > new > > > > "gt" test. > > > -> "-ge" > > Sure, changing to -ge fixes the problem: > > if [ $(($num_violations_new - $num_violations)) -ge $expected_violations ]; > > then > > I guess we need "-ge" for older kernels (unless "fix" for stable). Should > > we > > accept "$expected_violations || $expected_violations + 1" for new kernels to > > avoid problems like the one on my system. > The problem is that we don't control what else is running on the system. So > there could > be other violations independent of these tests. I'll have to think about it > some more and > get back to you. (There's no rush to do anything with these LTP IMA > violation tests.) OK, thank you. The worse scenario would be to use less precise variant "-ge". > > I wonder if the problem was somehow caused by the fact that I built kernel. > > OTOH > > it's build by OBS (official openSUSE build service). > As long as you weren't building the kernel and running the tests at the same, > I doubt it > would be the problem. Understand, just something on openSUSE Tumbleweed system. Kind regards, Petr > > I don't expect you'd have time to look into it, in case you're interested > > and > > have time sending a links to rpm binary and src package. > Ok. > > https://download.opensuse.org/repositories/home:/pevik:/ima-limit-open-writers-ToMToU/standard/x86_64/kernel-default-6.14~rc3-1.1.gb6b4102.x86_64.rpm > > https://download.opensuse.org/repositories/home:/pevik:/ima-limit-open-writers-ToMToU/standard/src/kernel-source-6.14~rc3-1.1.gb6b4102.src.rpm > thanks, > Mimi
