Bug 2172090
| Summary: | Missing policy: `allow domain tmpfile:file { append getattr ioctl lock open read }` | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Edward Haas <edwardh> |
| Component: | selinux-policy | Assignee: | Nikola Knazekova <nknazeko> |
| Status: | CLOSED MIGRATED | QA Contact: | Milos Malik <mmalik> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 9.2 | CC: | gveitmic, jlejosne, lpivarc, lvrabec, mduarted, mmalik, omosnace, zpytela |
| Target Milestone: | rc | Keywords: | MigratedToJIRA, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-08-23 08:31:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This seems to be a result of an upstream commit 7636e7cb798f [1] which is now also a part of RHEL 9 since rebasing selinux policy with selinux-policy-38.1.1-1.el9.
This commit removes the open permission for domains accessing generic tmp files which is defined in the files_read_inherited_tmp_files() interface, meaning the domains can still use inherited tmp file descriptors. The "open" permission was apparently put into the interface ("inherited") by mistake. This change seems to clash with applications which rely on the incorrect behaviour.
Can you elaborate on how the service works with the tmp files and which services are involved so that we can suggest a solution?
This issue does not take place in RHEL 8.
[1] https://github.com/fedora-selinux/selinux-policy/commit/7636e7cb798f570dd0a3578281edfe27a5023006
(In reply to Zdenek Pytela from comment #1) > Can you elaborate on how the service works with the tmp files and which > services are involved so that we can suggest a solution? On a Kubernetes (and its distributions, e.g. OpenShift) there is a kubelet agent [1] on each node. In order to create a Pod, kubelet is calling the CRI (e.g. cri-o [2]) which in turn calls CNI plugins to configure the networking part. The CNI plugin, in turn, just calls `nft` to setup nftables rules. When doing so, it uses a temporary file to place there the JSON config and later loads it. The actual implementation is in Go [3]. The actual usage of the temporary file came to resolve some other policy restriction, which seems to still not work today. Without the temp file, the data needs to be passed directly to STDIN. But this has been found not to work per my check (as described in the main comment). For reference, the usage without a temp file is here [4]. Please note that I think the same issue is seen on other CNI plugins, in particular Istio [5] one. At least this is what I saw a few weeks back. [1] https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ [2] https://github.com/cri-o/cri-o [3] https://github.com/networkplumbing/go-nft/blob/21bb0214d3f1595807a26379133bac8e9cea137d/nft/exec/exec.go#L62 [4] https://github.com/networkplumbing/go-nft/pull/51/files [5] https://github.com/istio/cni Please note that the AVC mentioned here is not the only iptables-related denial we're seeing, initially in Centos Stream 9 but now also in Centos Stream 8.
There's at least this second one:
avc: denied { ioctl } for pid=145398 comm="iptables" path="/sys/fs/cgroup" dev="tmpfs" ino=16618 scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0
(In reply to Jed Lejosne from comment #3) > Please note that the AVC mentioned here is not the only iptables-related > denial we're seeing, We'd like to have a reproducer or list of all denials so that the suggested fix is as complete as possible. > initially in Centos Stream 9 but now also in Centos > Stream 8. > There's at least this second one: > avc: denied { ioctl } for pid=145398 comm="iptables" > path="/sys/fs/cgroup" dev="tmpfs" ino=16618 > scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0 This is a problem different to the reported one, it anyway has been fixed in selinux-policy-3.14.3-111 in RHEL 8.8. Feel free to create a new RHEL/Centos 8 bz if you see any other denials. @zpytela any updates regarding the reported bug ? I mean the issue reported, and elaborated upon comment#2 . (In reply to Zdenek Pytela from comment #4) > (In reply to Jed Lejosne from comment #3) > > Please note that the AVC mentioned here is not the only iptables-related > > denial we're seeing, > > We'd like to have a reproducer or list of all denials so that the suggested > fix is as complete as possible. > > > initially in Centos Stream 9 but now also in Centos > > Stream 8. > > There's at least this second one: > > avc: denied { ioctl } for pid=145398 comm="iptables" > > path="/sys/fs/cgroup" dev="tmpfs" ino=16618 > > scontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0 > > This is a problem different to the reported one, it anyway has been fixed in > selinux-policy-3.14.3-111 in RHEL 8.8. > Feel free to create a new RHEL/Centos 8 bz if you see any other denials. Let's please focus on the reported issue; or are you @zpytela saying the reported issue was already fixed in this version ? Could you confirm ? (In reply to Miguel Duarte Barroso from comment #6) > Let's please focus on the reported issue; or are you @zpytela > saying the reported issue was already fixed in this version ? > > Could you confirm ? The reported issue is still in place, we are looking together for ways how to approach it (in the internal channels). The problem with cgroup has been addressed in both RHEL 8 and 9. Still happening on 4.13 rc.2
iptables_t to tmp_t not allowed
time->Wed Apr 12 04:55:31 2023
type=PROCTITLE msg=audit(1681275331.928:558): proctitle=6E6674002D6A002D66002F746D702F73706F6F66636865636B2D31323834303238343134
type=SYSCALL msg=audit(1681275331.928:558): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=7ffe57b48bb8 a2=0 a3=0 items=0 ppid=136903 pid=136913 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nft" exe="/usr/sbin/nft" subj=system_u:system_r:iptables_t:s0 key=(null)
type=AVC msg=audit(1681275331.928:558): avc: denied { open } for pid=136913 comm="nft" path="/tmp/spoofcheck-1284028414" dev="tmpfs" ino=18262 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=1
This is now working with KubeVirt, on a CentOS Stream 9 node. By working, I mean that the bridge plugin with the spoofcheck enabled is functional and is not being blocked by SELinux anymore. The snippet recreation in this BZ description is still not working, so I am guessing the labels changed when executing the binary. But I do not have a good established explanation to this. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |
Description of problem: On RHEL 9.2 / CentOS Stream 9 the policy that allowed access to the temp files disappeared. This is now failing processes like `nft` to use the `/tmp` folder to read the configuration. The problem has been detected on an OpenShift/Kubernetes virtualization deployment, where the CNI plugin failed to create the pod with the following audit message: ``` type=AVC msg=audit(1676970896.251:20214): avc: denied { open } for pid=195142 comm="nft" path="/tmp/spoofcheck-1864003494" dev="vda1" ino=133440 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0 ``` Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: ``` touch /tmp/spoofcheck-123456 chcon -u system_u -r object_r -t tmp_t /tmp/spoofcheck-123456 runcon system_u:system_r:iptables_t:s0 nft -j -f /tmp/spoofcheck-123456 ``` Actual results: ``` internal:0:0-0: Error: Could not open file "/tmp/spoofcheck-123456": Permission denied ``` Expected results: No failure. Additional info: There may be another rule that is missing, as even `/dev/stdin` is not working. ``` runcon system_u:system_r:iptables_t:s0 nft -j -f < /tmp/spoofcheck-123456 ``` Results with `internal:0:0-0: Error: Could not open file "/dev/stdin": Permission denied`.