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