All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org, ltp@lists.linux.it,
	Stefan Berger <stefanb@linux.ibm.com>
Subject: Re: [RFC PATCH 3/3] ima: additional ToMToU violation tests
Date: Fri, 21 Feb 2025 09:16:23 +0100	[thread overview]
Message-ID: <20250221081623.GA2739743@pevik> (raw)
In-Reply-To: <cd07d8052fbfa0cde426b4b07fde0c70e6aa046f.camel@linux.ibm.com>

> 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.

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

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org, ltp@lists.linux.it,
	Stefan Berger <stefanb@linux.ibm.com>
Subject: Re: [LTP] [RFC PATCH 3/3] ima: additional ToMToU violation tests
Date: Fri, 21 Feb 2025 09:16:23 +0100	[thread overview]
Message-ID: <20250221081623.GA2739743@pevik> (raw)
In-Reply-To: <cd07d8052fbfa0cde426b4b07fde0c70e6aa046f.camel@linux.ibm.com>

> 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.

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-02-21  8:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-20 16:00 [RFC PATCH 1/3] Update validate() to support multiple violations Mimi Zohar
2025-02-20 16:00 ` [LTP] " Mimi Zohar
2025-02-20 16:00 ` [RFC PATCH 2/3] ima: additional open-writer violation tests Mimi Zohar
2025-02-20 16:00   ` [LTP] " Mimi Zohar
2025-02-20 19:02   ` Petr Vorel
2025-02-20 19:02     ` [LTP] " Petr Vorel
2025-02-20 16:00 ` [RFC PATCH 3/3] ima: additional ToMToU " Mimi Zohar
2025-02-20 16:00   ` [LTP] " Mimi Zohar
2025-02-20 18:16   ` Petr Vorel
2025-02-20 18:16     ` [LTP] " Petr Vorel
2025-02-20 18:46     ` Petr Vorel
2025-02-20 18:46       ` [LTP] " Petr Vorel
2025-02-20 21:15       ` Mimi Zohar
2025-02-20 21:15         ` [LTP] " Mimi Zohar
2025-02-20 18:59     ` Mimi Zohar
2025-02-20 18:59       ` [LTP] " Mimi Zohar
2025-02-20 19:13       ` Petr Vorel
2025-02-20 19:13         ` [LTP] " Petr Vorel
2025-02-20 20:22         ` Mimi Zohar
2025-02-20 20:22           ` [LTP] " Mimi Zohar
2025-02-20 21:18           ` Mimi Zohar
2025-02-20 21:18             ` [LTP] " Mimi Zohar
2025-02-20 21:43             ` Petr Vorel
2025-02-20 21:43               ` [LTP] " Petr Vorel
2025-02-21  2:07               ` Mimi Zohar
2025-02-21  2:07                 ` [LTP] " Mimi Zohar
2025-02-21  8:16                 ` Petr Vorel [this message]
2025-02-21  8:16                   ` Petr Vorel
2025-02-24 18:48                   ` Mimi Zohar
2025-02-24 18:48                     ` [LTP] " Mimi Zohar
2025-02-25  7:45                     ` Petr Vorel
2025-02-25  7:45                       ` [LTP] " Petr Vorel
2025-02-20 18:50 ` [RFC PATCH 1/3] Update validate() to support multiple violations Petr Vorel
2025-02-20 18:50   ` [LTP] " Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250221081623.GA2739743@pevik \
    --to=pvorel@suse.cz \
    --cc=linux-integrity@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=stefanb@linux.ibm.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.