+++ This bug was initially created as a clone of Bug #2008097 +++
Description of problem:
[ 1591.423033] audit: type=1400 audit(1632734301.322:867): avc: denied { ioctl } for pid=11021 comm="iptables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1591.628670] audit: type=1400 audit(1632734301.528:868): avc: denied { ioctl } for pid=11022 comm="ip6tables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1651.420826] audit: type=1400 audit(1632734361.322:874): avc: denied { ioctl } for pid=11084 comm="iptables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1651.626716] audit: type=1400 audit(1632734361.528:875): avc: denied { ioctl } for pid=11085 comm="ip6tables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1711.418951] audit: type=1400 audit(1632734421.323:882): avc: denied { ioctl } for pid=11137 comm="iptables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1711.624370] audit: type=1400 audit(1632734421.528:883): avc: denied { ioctl } for pid=11139 comm="ip6tables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1771.416286] audit: type=1400 audit(1632734481.322:890): avc: denied { ioctl } for pid=11188 comm="iptables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1771.622655] audit: type=1400 audit(1632734481.528:891): avc: denied { ioctl } for pid=11190 comm="ip6tables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1831.413986] audit: type=1400 audit(1632734541.322:899): avc: denied { ioctl } for pid=11239 comm="iptables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
[ 1831.619931] audit: type=1400 audit(1632734541.528:900): avc: denied { ioctl } for pid=11241 comm="ip6tables" path="/sys/fs/cgroup" dev="tmpfs" ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
Version-Release number of selected component (if applicable):
Centos Stream 9
--- Additional comment from Sandro Bonazzola on 2021-09-27 12:47:59 UTC ---
workaround:
# echo '(allow iptables_t cgroup_t (dir (ioctl)))' >local_iptables.cil
# semodule -i local_iptables.cil
--- Additional comment from Zdenek Pytela on 2021-09-29 18:57:50 UTC ---
Hi Sandro,
Are ther some steps necessary to trigger these denials? Apart from the denials, do you also see some problem in the functionality?
--- Additional comment from Sandro Bonazzola on 2021-09-30 14:51:36 UTC ---
(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.
--- Additional comment from Zdenek Pytela on 2021-11-05 17:00:22 UTC ---
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
--- Additional comment from Sandro Bonazzola on 2021-12-02 13:31:51 UTC ---
# ausearch
-bash: ausearch: command not found
looks like ausearch is not included in Fedora CoreOS 34.
--- Additional comment from Zdenek Pytela on 2021-12-02 14:07:34 UTC ---
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?
--- Additional comment from Sandro Bonazzola on 2022-02-16 13:15:42 UTC ---
(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.
--- Additional comment from Zdenek Pytela on 2022-02-16 16:42:46 UTC ---
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/1083
--- Additional comment from Zdenek Pytela on 2022-03-14 13:31:13 UTC ---
--- Additional comment from Fedora Update System on 2022-04-12 09:13:07 UTC ---
FEDORA-2022-eaef082697 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-eaef082697
--- Additional comment from Fedora Update System on 2022-04-13 16:10:18 UTC ---
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.
--- Additional comment from Fedora Update System on 2022-04-17 23:07:45 UTC ---
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.
--- Additional comment from Fedora Update System on 2022-05-02 07:30:30 UTC ---
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.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:2483