search

oamg / leapp-repository

Leapp repositories containing actors for the Leapp framework (https://github.com/oamg/leapp). Currently provides leapp repositories for in-place upgrades of RHEL systems.
Apache License 2.0
48 stars 144 forks source link

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

Closed vmojzis closed 7 months ago

vmojzis commented 8 months ago

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[bot] commented 8 months ago

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:

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:

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

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

/packit test

vmojzis commented 8 months ago

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 commented 7 months ago

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

vmojzis commented 7 months ago 
# 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 commented 7 months ago

/packit build

fernflower commented 7 months ago

/packit test