Bug 2008097

workaround:

# echo '(allow iptables_t cgroup_t (dir (ioctl)))' >local_iptables.cil
# semodule -i local_iptables.cil

Hi Sandro,

Are ther some steps necessary to trigger these denials? Apart from the denials, do you also see some problem in the functionality?

(In reply to Zdenek Pytela from comment #2)
> Hi Sandro,
> 
> Are ther some steps necessary to trigger these denials? Apart from the
> denials, do you also see some problem in the functionality?

I installed latest Fedora CoreOS 34 stable passing ignition from OKD 4.8 series at https://amd64.origin.releases.ci.openshift.org/#4.8.0-0.okd .

The denials is raised after the system reboots.

It keeps showing up in the logs until you apply the workaround so I believe this means that the operation which is blocked by the denial is required to complete the installation successfully.

Sandro,

Will you be able to get additional details about the denial, without the workaround in place?

To enable full auditing:
1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run your scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

# ausearch
-bash: ausearch: command not found


looks like ausearch is not included in Fedora CoreOS 34.

OK, please answer a few questions then:
1. Is the workaround in #c1 sufficient?
2. Without the workaround in place, did you see any problems with functionality of some service?
3. Besides the data in #c0, are there any further information regarding the denials either in journal or dmesg?

(In reply to Zdenek Pytela from comment #6)
> OK, please answer a few questions then:
> 1. Is the workaround in #c1 sufficient?

Yes the workaround was enough to get the deployment working

> 2. Without the workaround in place, did you see any problems with
> functionality of some service?

Yes, OKD installation got stuck until the selinux denial was solved

> 3. Besides the data in #c0, are there any further information regarding the
> denials either in journal or dmesg?

I couldn't see anything more in the logs on the OS level. I didn't dig into the various pods / service logs.

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/1083

*** Bug 2061634 has been marked as a duplicate of this bug. ***

FEDORA-2022-eaef082697 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-eaef082697

FEDORA-2022-eaef082697 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-eaef082697`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-eaef082697

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-eaef082697 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-eaef082697`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-eaef082697

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-eaef082697 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.