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

[Mimi Zohar]

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.

Peter, thank you for the tumbleweed 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.

exec 3< $LOG || exit 1

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

thanks,

Mimi