QA (public) » openQA Project (public) » openQA Tests (public)

ah and just to make sure: the apparmor tests should still continue to be run if apparmor is selected in the installer, so please do not drop them

not sure if @dimstar or @jsegitz have any more points

we could also add a mechanism to whitelist AVC entries for a certain time. We will have regularly new AVCs, which will require some time to get a fix into the policy. If we would just softfail the test then I fear that this might pile up. Having a mechanism to say "ignore this AVC in this test for one month" would be a nice way to unblock testing, while making sure that this doesn't become permanent

cahu wrote in #note-2:

There are a few points:

• the policy will then already be enabled directly after the installation, so tests for "if enabling works" should only be run for scenarios where it is not yet enabled (e.g. UPGRADE from old tumbleweed and the user wants to switch from apparmor to selinux or UPGRADE from old leap that has apparmor); there we should test if manually switching from apparmor works to selinux targeted enforcing and minimum enforcing (the user guide: https://en.opensuse.org/Portal:SELinux/Setup#Setup_SELinux_on_existing_tumbleweed_systems).

Done.

• in general, ( the most important thing ) when SELinux is enabled the audit log should be checked for AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR entries in the audit log after every test in the whole openQA test set so that we can see if policy changes break the functionality; this is partially already done, so it makes sense to check where it is not the case

This is implemented by printing new entries from audit.log at the end of each openQA module. However, the content is simply displayed but not acted upon. In this state it'll be mostly useful for debugging module failures but not noticing denials that do not immediately cause module failures.

• the toolchain tests should also be done in targeted mode (currently they seem to be done in minimum only)

Done with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/21005, which then only uses the targeted policy.

• testing switching from targeted to minimum and back should be done (with audit log)

Currently not the case, how important is this?

nice thx for working on this :)

• in general, ( the most important thing ) when SELinux is enabled the audit log should be checked for AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR entries in the audit log after every test in the whole openQA test set so that we can see if policy changes break the functionality; this is partially already done, so it makes sense to check where it is not the case

This is implemented by printing new entries from audit.log at the end of each openQA module. However, the content is simply displayed but not acted upon. In this state it'll be mostly useful for debugging module failures but not noticing denials that do not immediately cause module failures.

how hard is it to implement module failures when permissive=0 is there in the AVC?

• testing switching from targeted to minimum and back should be done (with audit log)

Currently not the case, how important is this?

imo low prio, but should be done at some point in time

cahu wrote in #note-7:

nice thx for working on this :)

• in general, ( the most important thing ) when SELinux is enabled the audit log should be checked for AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR entries in the audit log after every test in the whole openQA test set so that we can see if policy changes break the functionality; this is partially already done, so it makes sense to check where it is not the case

This is implemented by printing new entries from audit.log at the end of each openQA module. However, the content is simply displayed but not acted upon. In this state it'll be mostly useful for debugging module failures but not noticing denials that do not immediately cause module failures.

how hard is it to implement module failures when permissive=0 is there in the AVC?

Trivial, but the question is how much work this will cause. It will probably need a whitelist mechanism with more or less temporary entries, just like journal_check.

• testing switching from targeted to minimum and back should be done (with audit log)

Currently not the case, how important is this?

imo low prio, but should be done at some point in time