SELinux: Work around "semanage import bug" RHEL-3295

[vmojzis]

https://issues.redhat.com/browse/RHEL-3295

The bug can be triggered with customizations such as:

      semanage port -m -t ssh_port_t -p tcp 8021
      semanage port -m -t ssh_port_t -p tcp 2888
      semanage user -m user_u -R user_r -R staff_r
      semanage user -m staff_u -R user_r
      semanage login -m -s guest_u __default__ -r s0
      semanage fcontext -m -t httpd_sys_content_t "/vmlinuz.*" -f l
      semanage fcontext -m -t httpd_sys_content_t "/xen(/.*)?"

jira: RHEL-3295

[github-actions]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

• review please @oamg/developers to notify leapp developers of the review request
• /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp from PR#42, use /packit test oamg/leapp#42

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

• /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
• /packit test --labels beaker-minimal-8.9to9.3,kernel-rt-8.9to9.3 to schedule kernel-rt and beaker-minimal test sets for 8.9->9.3 upgrade path

[Deprecated] To launch on-demand regression testing public members of oamg organization can leave the following comment:

• /rerun to schedule basic regression tests using this pr build and latest upstream leapp build as artifacts
• /rerun 42 to schedule basic regression tests using this pr build and leapp*PR42* as artifacts
• /rerun-sst to schedule sst tests using this pr build and latest upstream leapp build as artifacts
• /rerun-sst 42 to schedule sst tests using this pr build and leapp*PR42* as artifacts

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

[vmojzis]

I'd like to test this change properly (i.e. add policy customizations that would trigger the bug), but https://gitlab.cee.redhat.com/leapp/oamg-rhel8-vagrant does not work for me (ERROR! couldn't resolve module/action 'redhat_subscription'). Are there any other ways?

[vmojzis]

Could you please point me to some instructions on how to run the tests with "DESTRUCTIVE_TESTING=True" ? I don't know of a way to test this without possibly modifying the underlying system.

[fernflower]

Hi @vmojzis !
As a team we have moved away from writing and running destructive unit tests in favor of dealing with anything remotely destructive in our tmt/tft based integration testing framework. So the DESTRUCTIVE_TESTING marked tests are leftovers that are not being run and supported at the moment.
But if you'd like to run this test anyway, a bit hackish approach comes to mind - to prepare a containerized environment (our Makefile is capable of that) and run the test there.
This should do the trick

1. Prepare the containerized environment (rhel8 by default, can be controlled by setting _TEST_CONTAINER env var). You can kill all tests execution right after container setup has been finished.

make test_container_no_lint

2. Run specifically the destructive test. ACTOR helps to limit the tests to the specific actor only, DESTRUCTIVE_TESTING env var will enable the skipped-by-default-destructive test.

podman exec leapp-repo-tests-rhel8-cont bash -c 'cd /repocopy; ACTOR=selinuxprepare DESTRUCTIVE_TESTING=True make test_no_lint'

Hope it helps!

[fernflower]

But to be honest I believe we should add a proper integration test:

1. Add customizations
2. Attempt an upgrade
3. Check for errors and confirm that report matches what's expected

Although I managed to run the existing destructive selinux test I am getting an ERROR

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
repos/system_upgrade/common/actors/selinux/selinuxprepare/tests/component_test_selinuxprepare.py:35: in _run_cmd
    return run(cmd, split=split).get('stdout', '')
tut/lib/python3.6/site-packages/leapp/libraries/stdlib/__init__.py:213: in run
    'process-result', {'id': _id, 'parameters': args, 'result': audit_result, 'env': env}
tut/lib/python3.6/site-packages/leapp/utils/audit/__init__.py:286: in create_audit_entry
    'data': data
tut/lib/python3.6/site-packages/leapp/utils/audit/__init__.py:87: in store
    with get_connection(db) as connection:
tut/lib/python3.6/site-packages/leapp/utils/audit/__init__.py:73: in get_connection
    return create_connection(cfg.get('database', 'path'))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

[fernflower]

Could not let it go - looks like container was missing several selinux related packages, after installing policycoreutils-python-utils, policycoreutils, selinux-policy-targeted things started to look much-much better :)

So this is a viable workaround. Sorry for the noise :)

[fernflower]

/packit test

[vmojzis]

But to be honest I believe we should add a proper integration test:

1. Add customizations
2. Attempt an upgrade
3. Check for errors and confirm that report matches what's expected

That sounds great. Could you please point me to a simple existing integration test I could use as a template? The "destructive" tests we currently have for selinux actors should already contain all the pieces, so I just need to put it together.

[fernflower]

@vmojzis Could you please describe the test scenario? I will help to convert it into leapp integration test in our downstream framework.

[vmojzis]

# dnf install container-selinux policycoreutils-python-utils policycoreutils

## [0] should be removed by the actors (el8 to el9 only)
## the rest should be re-applied
## The last 4 commands cannot be re-applied without tweaking the commands
## (testing the fix for "semanage export" bug where "-a" is exported instead of "-m")
# semanage fcontext -a -t cgdcbxd_var_run_t '/ganesha(/.*)?'
# semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?'
# semanage port -a -t http_port_t -p udp 81
# semanage port -m -t ssh_port_t -p tcp 8021
# semanage user -m user_u -R user_r -R staff_r
# semanage login -m -s guest_u __default__ -r s0
# semanage fcontext -m -t httpd_sys_content_t "/vmlinuz.*" -f l

# semodule -X 400 -i mock1.cil
# semodule -X 99 -i mock1.cil
# semodule -X 200 -i mock1.cil
# semodule -X 400 -i mock2.cil
# semodule -X 999 -i mock3.cil
# semodule -X 200 -i base_container.cil

^^^ needs repos/system_upgrade/common/actors/selinux/selinuxcontentscanner/tests/mock_modules from https://github.com/oamg/leapp-repository/ (all except compat.cil)

---

system upgrade

expected "semanage export" output after upgrade (the first 11 lines are always present -- no need to test for them):

# semanage export
boolean -D
login -D
interface -D
user -D
port -D
node -D
fcontext -D
module -D
ibendport -D
ibpkey -D
permissive -D
login -a -s guest_u -r 's0' __default__
user -a -L s0 -r s0 -R 'user_r staff_r' user_u
port -a -t http_port_t -r 's0' -p udp 81
port -a -t ssh_port_t -r 's0' -p tcp 8021
fcontext -a -f l -t httpd_sys_content_t -r 's0' '/vmlinuz.*'
fcontext -a -f a -t httpd_sys_content_t -r 's0' '/web(/.*)?'

expected modules after upgade (there will probably be others, brought in by *-selinux packages):

# semodule -lfull | grep -v 100
999 mock3             cil
400 mock1             cil
400 mock2             cil
200 base_container    cil
200 container         pp
200 mock1             cil
099 mock1             cil

[fernflower]

/packit build

[fernflower]

/packit test

[fernflower]

lgtm, tests passed