Bug 1754719
| Summary: | [RHEL-8] avc: denied { write } for pid=3026 comm="ibacm" name="shm" dev="devtmpfs" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | zguo <zguo> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.1 | CC: | honli, lvrabec, mmalik, omosnace, plautrba, ssekidde, zpytela |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 01:55:53 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1802014 | ||
|
Description
zguo
2019-09-24 02:10:25 UTC
Could you tell me the whole path to "shm" directory which is mentioned in the SELinux denial? The "ino=15466" part of the SELinux denial indicates the inode number. # find / -type d -inum 15466 Unfortunately, the inode number can be different on each machine. If the "shm" directory is in fact /dev/shm directory, then it is mislabeled. The correct label for /dev/shm is tmpfs_t: $ matchpathcon /dev/shm /dev/shm system_u:object_r:tmpfs_t:s0 $ I ran another test, https://beaker.engineering.redhat.com/jobs/3837163 https://beaker.engineering.redhat.com/recipes/7460083/tasks/100675158/results/463431172/logs/avc.log [root@rdma-perf-01 ~]$ find / -type d -inum 19468 /dev/shm find: ‘/proc/27613’: No such file or directory [root@rdma-perf-01 ~]$ matchpathcon /dev/shm /dev/shm system_u:object_r:tmpfs_t:s0 *** Bug 1813841 has been marked as a duplicate of this bug. *** Hi,
I'd like to start with the write permission. The /dev/shm is a tmpfs filesystem with the default tmpfs_t type. In the denials, we can see a write attempt:
time->Fri Mar 13 05:38:22 2020
type=AVC msg=audit(1584092302.386:591): avc: denied { write } for pid=188857 comm="ibacm" name="shm" dev="devtmpfs" ino=24617 scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=dir permissive=0
actually to devtmpfs which should be mounted on the parent directory, to a filename in comment c#2 isolated as /dev/shm. Is it possible that at some point of the test the /dev/shm filesystem was unmounted and the directory removed?
Please run the following commands at the time of the denials reported:
ls -Zla /dev/shm
cat /proc/mounts
(In reply to Zdenek Pytela from comment #5) > Hi, > > I'd like to start with the write permission. The /dev/shm is a tmpfs > filesystem with the default tmpfs_t type. In the denials, we can see a write > attempt: > > time->Fri Mar 13 05:38:22 2020 > type=AVC msg=audit(1584092302.386:591): avc: denied { write } for > pid=188857 comm="ibacm" name="shm" dev="devtmpfs" ino=24617 > scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:object_r:device_t:s0 > tclass=dir permissive=0 > > actually to devtmpfs which should be mounted on the parent directory, to a > filename in comment c#2 isolated as /dev/shm. Is it possible that at some > point of the test the /dev/shm filesystem was unmounted and the directory > removed? > > Please run the following commands at the time of the denials reported: > > ls -Zla /dev/shm > cat /proc/mounts [root@rdma-qe-14 ~]$ ls -Zla /dev/shm total 4 drwxrwxrwt. 2 root root system_u:object_r:tmpfs_t:s0 60 Mar 19 22:27 . drwxr-xr-x. 21 root root system_u:object_r:device_t:s0 3280 Mar 20 2020 .. -rw-r--r--. 1 root root system_u:object_r:ibacm_tmpfs_t:s0 160 Mar 19 22:33 INTEL_SA_DSC [root@rdma-qe-14 ~]$ cat /proc/mounts sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=16317908k,nr_inodes=4079477,mode=755 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0 devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,seclabel,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,seclabel,nosuid,nodev,noexec,relatime 0 0 bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,seclabel,nosuid,nodev,noexec,relatime,pids 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,seclabel,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,seclabel,nosuid,nodev,noexec,relatime,hugetlb 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,seclabel,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/rdma cgroup rw,seclabel,nosuid,nodev,noexec,relatime,rdma 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,seclabel,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,seclabel,nosuid,nodev,noexec,relatime,perf_event 0 0 configfs /sys/kernel/config configfs rw,relatime 0 0 /dev/mapper/rhel_rdma--qe--14-root / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=39,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=26798 0 0 debugfs /sys/kernel/debug debugfs rw,seclabel,relatime 0 0 mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime,pagesize=2M 0 0 /dev/sda1 /boot xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 /dev/mapper/rhel_rdma--qe--14-home /home xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 tmpfs /run/user/0 tmpfs rw,seclabel,nosuid,nodev,relatime,size=3267152k,mode=700 0 0 Thank you for the commands output, it looks correct, type for /dev/shm is tmpfs_t and the tmpfs filesystem is mounted. Are there any AVC denials audited now? (In reply to Zdenek Pytela from comment #7) > Thank you for the commands output, it looks correct, type for /dev/shm is > tmpfs_t and the tmpfs filesystem is mounted. Are there any AVC denials > audited now? Did not notice denied { write }, still can see below denied. [root@rdma-qe-14 ~]$ rpm -q selinux-policy selinux-policy-3.14.3-41.el8.noarch type=AVC msg=audit(1584671533.260:199): avc: denied { create } for pid=29470 comm="sm" scontext=system_u:system_r:opafm_t:s0 tcontext=system_u:system_r:opafm_t:s0 tclass=netlink_rdma_socket permissive=0 type=AVC msg=audit(1584671536.105:200): avc: denied { ipc_lock } for pid=29188 comm="ibacm" capability=14 scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:system_r:ibacm_t:s0 tclass=capability permissive=0 type=SERVICE_START msg=audit(1584671543.905:201): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'^]UID="root" AUID="unset" type=SERVICE_STOP msg=audit(1584671554.078:202): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'^]UID="root" AUID="unset" type=SERVICE_START msg=audit(1584671589.611:203): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=ibacm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'^]UID="root" AUID="unset" type=SERVICE_STOP msg=audit(1584671589.611:204): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=ibacm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'^]UID="root" AUID="unset" type=AVC msg=audit(1584671589.620:205): avc: denied { ipc_lock } for pid=29604 comm="ibacm" capability=14 scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:system_r:ibacm_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1584671589.626:206): avc: denied { ipc_lock } for pid=29604 comm="ibacm" capability=14 scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:system_r:ibacm_t:s0 tclass=capability permissive=0 type=AVC msg=audit(1584671589.634:207): avc: denied { ipc_lock } for pid=29604 comm="ibacm" capability=14 scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:system_r:ibacm_t:s0 tclass=capability permissive=0 Hi, ibacm requests this capability: /* Allow locking of shared memory segments */ /* Allow mlock and mlockall (which doesn't really have anything to do with IPC) */ #define CAP_IPC_LOCK 14 Is it correct and expected? The netlink_rdma_socket permission will be allowed with resolving the following bz: https://bugzilla.redhat.com/show_bug.cgi?id=1786670 (In reply to Zdenek Pytela from comment #10) > Hi, > > ibacm requests this capability: > > /* Allow locking of shared memory segments */ > /* Allow mlock and mlockall (which doesn't really have anything to do > with IPC) */ > > #define CAP_IPC_LOCK 14 > > Is it correct and expected? Why you suspect it may be incorrect? I tried to locate which function in ibacm requests this capability. But I failed. I tried to check the mlock/mlockall/mmap/shmctl functions in source code. How to locate which function triggered the AVC message? thanks (In reply to Honggang LI from comment #12) > (In reply to Zdenek Pytela from comment #10) > > Hi, > > > > ibacm requests this capability: > > > > /* Allow locking of shared memory segments */ > > /* Allow mlock and mlockall (which doesn't really have anything to do > > with IPC) */ > > > > #define CAP_IPC_LOCK 14 > > > > Is it correct and expected? > > Why you suspect it may be incorrect? It is not considered as suspect, but rather caution is in place. If a new permission is required, is it due to a new functionality or is it a side-effect of some other change? What has changed in the software recently? Questions like this need to be answered first. > I tried to locate which function in ibacm requests this capability. But I > failed. > I tried to check the mlock/mlockall/mmap/shmctl functions in source code. > > How to locate which function triggered the AVC message? Full auditing can be enabled with a similar command: auditctl -w /etc/shadow -p w -k shadow-write so that additional data, which may turn out to be useful, are audited. (In reply to Zdenek Pytela from comment #13) > (In reply to Honggang LI from comment #12) > > (In reply to Zdenek Pytela from comment #10) > > > Hi, > > > > > > ibacm requests this capability: > > > > > > /* Allow locking of shared memory segments */ > > > /* Allow mlock and mlockall (which doesn't really have anything to do > > > with IPC) */ > > > > > > #define CAP_IPC_LOCK 14 > > > > > > Is it correct and expected? > > > > Why you suspect it may be incorrect? > It is not considered as suspect, but rather caution is in place. If a new > permission is required, is it due to a new functionality or is it a > side-effect of some other change? What has changed in the software recently? > Questions like this need to be answered first. kernel drivers/infiniband/core changes between kernel-4.18.0-80.el8 and kernel-4.18.0-81.el8 requests the new permission. (In reply to Honggang LI from comment #14) > kernel drivers/infiniband/core changes between kernel-4.18.0-80.el8 and > kernel-4.18.0-81.el8 requests the new permission. Ah, looks like the backport of this commit caused it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4b4dd1b9706e48c370f88d3adfe713e43423cc9 Not familiar with Infiniband, but from the code it looks like the need to lock memory is inherently needed when interfacing with the Infiniband driver, so I'd say the need for CAP_IPC_LOCK is justified here. It wasn't needed before only as a result of kernel bug (IIUC). Thank you for helping us identify the root cause, Honggang! I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/224 For the record: There were also 2 other permission mentioned earlier in the bug: type=AVC msg=audit(1584092302.386:591): avc: denied { write } for pid=188857 comm="ibacm" name="shm" dev="devtmpfs" ino=24617 scontext=system_u:system_r:ibacm_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=dir permissive=0 This one was not reproduced again. type=AVC msg=audit(1584671533.260:199): avc: denied { create } for pid=29470 comm="sm" scontext=system_u:system_r:opafm_t:s0 tcontext=system_u:system_r:opafm_t:s0 tclass=netlink_rdma_socket permissive=0 Handled in https://bugzilla.redhat.com/show_bug.cgi?id=1786670. Based on comment #2, is expected to be fixed in RHEL 8.3. Fixed in Fedora:
commit b5e7044dbca7f591d275e9b7895ad6e76e3ca906 (HEAD -> rawhide, origin/rawhide, origin/HEAD)
Author: Zdenek Pytela <zpytela>
Date: Tue Mar 24 15:28:35 2020 +0100
Add ibacm_t ipc_lock capability
Add ibacm_t the ipc_lock capability to support the update in kernel
to handle memory locking when interfacing with the Infiniband driver.
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-2020:4528 |