Automatically handle SELinux for port customization

[martinpitt]

Use the selinux system role for this.

---

Follow-up from PR #67.

[martinpitt]

@richm: Is it legit to simply use them like that? Upstream they are in separate repos, but downstream they'd always be delivered in the same "linux-system-roles" or "rhel-system-roles" package, right? Or should I move the git clone from the test to here?

[richm]

You should use the following form:

include_role:
  name: fedora.linux_system_roles.selinux

see https://linux-system-roles.github.io/documentation/role-requirements.html

[martinpitt]

Does that work for RHEL as well? Both our README and our current tests use name: linux-system-roles.*.

[richm]

Does that work for RHEL as well? Both our README and our current tests use name: linux-system-roles.*.

It will. When we build the RPM for RHEL, we already have to do some rebranding of fedora -> redhat and linux-system-roles -> rhel-system-roles - there will be an additional rebranding step to convert fedora.linux_system_roles -> redhat.rhel_system_roles.

[richm]

The README is problematic - I'm not sure how to convey that you can use one of the 4 different versions of the role: linux-system-roles.cockpit or fedora.linux_system_roles.cockpit or rhel-system-roles.cockpit or redhat.rhel_system_roles.cockpit in all of the examples - when we do build the collection and/or downstream the cockpit role, we do update the README.

[martinpitt]

I tried to test this on Debian stable, but that fails, as lsr-selinux tries to install a nonexisting package:

fatal: [d]: FAILED! => {"changed": false, "msg": "No package matching 'libselinux-python3' is available"}

The same happens in CI.

This would be fixable, but the SELinux role also does not handle distributions without SELinux. If I fix the package problem locally:

ASK [linux-system-roles.selinux : Set an SELinux label on a port] *********************************************************************
task path: /var/home/martin/upstream/lsr-cockpit/tests/roles/linux-system-roles.selinux/tasks/main.yml:90
redirecting (type: modules) ansible.builtin.seport to community.general.seport
redirecting (type: modules) ansible.builtin.seport to community.general.seport
failed: [d] (item={'ports': 443, 'proto': 'tcp', 'setype': 'websm_port_t', 'state': 'present'}) => {"ansible_loop_var": "item", "changed": false, "item": {"ports": 443, "proto": "tcp", "setype": "websm_port_t", "state": "present"}, "msg": "SELinux is disabled on this host."}

So I suppose it's best to explicitly test that in the cockpit role, and only conditionally run the selinux role.

[martinpitt]

The integration tests also fail with what looks like a bug in the selinux role itself?

TASK [Allow cockpit to own custom port in SELinux policy] **********************
task path: /tmp/tmpown5y4o2/ansible_collections/fedora/linux_system_roles/roles/cockpit/tasks/main.yml:50
Wednesday 03 August 2022  07:34:41 +0000 (0:00:01.020)       0:00:17.039 ****** 
redirecting (type: modules) ansible.builtin.selinux to ansible.posix.selinux
ERROR! couldn't resolve module/action 'selinux'. This often indicates a misspelling, missing collection, or incorrect module path.

The most recent selinux role tests were all run with "[citest skip]". The last one that wasn't failed pretty hard.

[martinpitt]

@richm : Friendly ping? I have some questions above. Thanks!

[richm]

So I suppose it's best to explicitly test that in the cockpit role, and only conditionally run the selinux role.

Yes. Don't use the selinux role if the selinux role is not supported on that platform. Probably, only use the selinux role on EL and Fedora.

[richm]

The integration tests also fail with what looks like a bug in the selinux role itself?

TASK [Allow cockpit to own custom port in SELinux policy] **********************
task path: /tmp/tmpown5y4o2/ansible_collections/fedora/linux_system_roles/roles/cockpit/tasks/main.yml:50
Wednesday 03 August 2022  07:34:41 +0000 (0:00:01.020)       0:00:17.039 ****** 
redirecting (type: modules) ansible.builtin.selinux to ansible.posix.selinux
ERROR! couldn't resolve module/action 'selinux'. This often indicates a misspelling, missing collection, or incorrect module path.

The most recent selinux role tests were all run with "[citest skip]". The last one that wasn't failed pretty hard.

What version of ansible was that test run with? Note that ansible-core 2.13 does not support rhel6 managed nodes.

[richm]

So I suppose it's best to explicitly test that in the cockpit role, and only conditionally run the selinux role.

Yes. Don't use the selinux role if the selinux role is not supported on that platform. Probably, only use the selinux role on EL and Fedora.

And - if that means it makes the cockpit role too complex or difficult to support, because the selinux role is used on some platforms and not on others, then it might not be worth using the selinux role at all, and we'll just have to live with adding documentation about how to configure selinux to allow the port on the various platforms that support selinux.

[richm]

In addition to the above - we are still waiting for baseos CI to roll-out support for being able to install and use system roles from other system roles - so really none of this will work until that happens, which should be Real Soon Now(tm). Please ping me directly and I can give you some links to follow about the baseos ci progress.

[martinpitt]

What version of ansible was that test run with? Note that ansible-core 2.13 does not support rhel6 managed nodes.

A bit hard to say from the logs, but "ansible-galaxy 2.9.27" sounds plausible?

[richm]

[citest bad]

[martinpitt]

And - if that means it makes the cockpit role too complex or difficult to support, because the selinux role is used on some platforms and not on others,

It should work now -- it tests for selinux first, and conditionally includes the role. Not sure if you would count that as "too complex", but at least it's gated by tests.

But I suppose all the tests here fail due to the "waiting for baseos CI to roll-out support for being able to install and use system roles from other system roles" issue? Then I guess I'll block this for the time being. Of course our role could just automatically do the "semanage port" command call directly instead of invoking the role, but that somehow feels dirty to me -- however, I don't have a qualified opinion on that.

[richm]

ok - note that the legacy CI (the systemroller icon - the labels of the form platform-x/ansible-2.x) is now gone (lab has been deprovisioned) - the only CI now is the baseos ci (tft-bot icon - labels ending with (citool)) - note that we're still waiting for dependency installation support, so the 2.13 tests will fail - but let's see if we get a good result on the 2.9 tests, including the RHEL-6 tests

[richm]

And - if that means it makes the cockpit role too complex or difficult to support, because the selinux role is used on some platforms and not on others,

It should work now -- it tests for selinux first, and conditionally includes the role. Not sure if you would count that as "too complex", but at least it's gated by tests.

But I suppose all the tests here fail due to the "waiting for baseos CI to roll-out support for being able to install and use system roles from other system roles" issue?

Yes.

Then I guess I'll block this for the time being.

ok.

Of course our role could just automatically do the "semanage port" command call directly instead of invoking the role, but that somehow feels dirty to me -- however, I don't have a qualified opinion on that.

That's problematic for a few reasons - see linux-system-roles/selinux#122 (comment)

[richm]

[citest]

[richm]

@martinpitt ping

[martinpitt]

@richm Sorry, I wasn't aware that this is blocking on me -- TBH I don't quite know what to change here. From my POV this is still broken by the CI's inability to fetch the selinux role, or even making up our minds whether we want to do this at all. I'm currently rather busy with finishing up some other projects, and will move team until the end of this year, so I'll most probably not get to this anytime soon. So I'd just shelve it for the time being.

[richm]

@richm Sorry, I wasn't aware that this is blocking on me -- TBH I don't quite know what to change here. From my POV this is still broken by the CI's inability to fetch the selinux role,

It is, just not in the way it is done in this PR - see https://linux-system-roles.github.io/documentation/role-requirements.html

or even making up our minds whether we want to do this at all.

We are in the process of converting many of the system roles to use firewall/selinux/certificate - for example linux-system-roles/logging#293

I'm currently rather busy with finishing up some other projects, and will move team until the end of this year, so I'll most probably not get to this anytime soon. So I'd just shelve it for the time being.

Ok. Then, @nhosoi I suggest you create a new PR based on this one, or just code it up from scratch.

[nhosoi]

@richm Sorry, I wasn't aware that this is blocking on me -- TBH I don't quite know what to change here. From my POV this is still broken by the CI's inability to fetch the selinux role,

It is, just not in the way it is done in this PR - see https://linux-system-roles.github.io/documentation/role-requirements.html

or even making up our minds whether we want to do this at all.

We are in the process of converting many of the system roles to use firewall/selinux/certificate - for example linux-system-roles/logging#293

I'm currently rather busy with finishing up some other projects, and will move team until the end of this year, so I'll most probably not get to this anytime soon. So I'd just shelve it for the time being.

Ok. Then, @nhosoi I suggest you create a new PR based on this one, or just code it up from scratch.

@richm, @martinpitt, I've submitted #76, which has the similar api as the other roles do. Currently, the first batch of CI tests are running. Once they pass, could you please review the #76?

I guess, we'd also like to use the certificate role for this generating cert case: https://github.com/linux-system-roles/cockpit/#generate-a-new-certificate. I'm thinking to work on that in a separate pr. Hope it's ok... Thanks.

[martinpitt]

Closing in favor of #76, thanks @nhosoi !