[LTP] [PATCH] security/ima: limit the scope of the LTP policy rules based on the UUID

[Petr Vorel]

> On Thu, 2022-12-15 at 19:39 +0100, Petr Vorel wrote:
> > Hi Mimi,

> > I'm sorry, it took me long time to look into the issue.

> > > Only the ima_conditionals.sh and ima_policy.sh tests define policy
> > > rules based on fsuuid.  The other tests are still based on the builtin
> > > "ima_policy=tcb" rules.
> > Yes.

> < trimmed >

> > 4) running ima_violations.sh after ima_policy.sh no longer works, because
> > there is nothing new in /var/log/audit/audit.log. I don't know why, but
> > ima_violations.sh requires either the default ima_policy=tcb policy or policy
> > created by ima_policy.sh *without* fsuuid.

> Violations occur when a file in policy is already opened for read and
> is being opened for write, or the reverse.  After the builtin policy is
> replaced with the custom policy based on the UUID, running the
> violation test fails because the UUID is reset by the call to
> ima_setup().  So the file being opened doesn't match any policy rule.
Yes, I was just surprised that test ima_violations.sh really depends on
ima_policy=tcb or policy created by ima_policy.sh test.

This also means if somebody wants to test just ima_violations.sh,
he would need to have ima_policy=tcb. Dependency between IMA tests
is something LTP does not expect nor want.

Unfortunately due failures described above it'd be not good to accept this
patch.  But it's a very nice proof of concept how to use fsuuid, thank you.

> > FYI below is content of /var/log/audit/audit.log.

> > Also looking at things twice, fsuuid does not help testing much.
> > Because main blocker for testing is not the scope of the policy, but write once
> > policy - CONFIG_IMA_WRITE_POLICY not being set on distro kernels thus repeated
> > write of the policy will need reboot.

> Oh, I didn't realize this.  Fedora (and RHEL) enable
> CONFIG_IMA_WRITE_POLICY.
Yes, but this config is 'n' by default. I wonder: shouldn't it be 'y' by
default, so that people who does not care get it enabled? Or is it a security
concern to get it enabled during just on boot by systemd?

Even if it were 'y' by default, there still might be some distros/people who
disable it... This is the source of all complications.

> > Rebooting actually might be possible sooner or later with new runltp-ng from
> > Andrea [1] (the feature is not here yet, but will be sooner or later). runltp-ng
> > is close to upstream, there was first attempt [2].

> Let's try to avoid this solution as much as possible.
Sure, reboot is complication.

But you need to accept exact order of the tests. Or have detection,
but the detection does not work on disabled CONFIG_IMA_READ_POLICY
(which is the default when CONFIG_IMA_WRITE_POLICY is not set - again people can
have it unset). Actually ima_kexec.sh has broken detection - this gives TWARN
and TBROK (= failure) on disabled CONFIG_IMA_READ_POLICY:

		if [ "$policy_readable" != 1 ]; then
			tst_res TWARN "policy not readable, it might not contain required policy '$REQUIRED_POLICY'"
			res=TBROK
		fi
		tst_brk $res "unable to find a correct measurement"

Exact order is first test anything with ima_policy=tcb, then have custom policy.
Also, one should run tests with no IMA setup, then with ima_policy=tcb. Then
there are other unsupported/untested policies: ima_policy=secure_boot and
ima_policy=appraise_tcb, supporting them would obviously require reboot.

> > Other option would be to prepare policy which would be suitable for all tests,
> > with help of fsuuid.

> Ok, I'll look into this.
Thank you, very much appreciated!

> > But that has drawback:
> > Currently we use LTP API to mount directories on loop device after test has started.
> > These devices are temporary, e.g.
> > /tmp/LTP_ima_violations.pEvyfJO7Af/mntpoint/test.txt will be unmounted and
> > deleted after each test run. But for fsuuid we'd need to first permanently
> > mount the devices to get their UUID. Therefore there would have to be some
> > special setup script needed to be run for all tests. This has proven to be
> > problematic in the past. I'd have to extend the API to create something permanent.

> Instead of ima_setup() setting the UUID to a new different value, if
> additional rules cannot be written (require_policy_writable) the UUID
> could be set to the existing policy rules UUID.
Not sure if I understand you. FYI no mounted directory exists before test run,
nothing survives after test finishes.
Test is supposed to write *only* to it's temporary directory $TST_TMPDIR, which
is created by TST_NEEDS_TMPDIR=1 after test has started, this is the directory
which gets deleted.

Kind regards,
Petr