Re: [RFC PATCH 3/3] ima: additional ToMToU violation tests

[Petr Vorel <pvorel@suse.cz>]

> On Fri, 2025-02-21 at 09:16 +0100, Petr Vorel wrote:
> > > 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-zohar@linux.ibm.com/
> > > > > > > > > > Signed-off-by: Mimi Zohar <zohar@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.

Hi Mimi,

> Peter, thank you for the tumbleweed image.

Thanks for debugging on the image!

> The default IMA tcb policy results is measuring $LOG (/var/log/audit/audit.log)
> on the first call to validate().  To prevent that from interfering with test1, I
> would add the following line or something similar in setup() to force measuring
> $LOG to happen earlier.

+1

> exec 3< $LOG || exit 1
Ideally use:
exec 3< $LOG || tst_brk TBROK "some explanation..."

> Assuming that works, I'll update the kernel and LTP tests.

+1 (patch from you is preferred)

Kind regards,
Petr

> thanks,

> Mimi