Bug 1820798

Can you collect SELinux denials triggered during "Steps to Reproduce" and attach them here?

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Thank you.

Here's the denial I just generated from my test system.  It does not have a nvme drive, but this can be replicated using the nvme_device_t context type

# ls -lZ /dev/sdb 
brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 8, 16 Apr  3 17:22 /dev/sdb


# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today
----
type=PROCTITLE msg=audit(04/13/2020 02:33:01.114:4497) : proctitle=/usr/libexec/platform-python /usr/libexec/rhsmcertd-worker 
type=SYSCALL msg=audit(04/13/2020 02:33:01.114:4497) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x5575999e8fc0 a2=O_RDONLY a3=0x0 items=0 ppid=888 pid=19188 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rhsmcertd-worke exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null) 
type=AVC msg=audit(04/13/2020 02:33:01.114:4497) : avc:  denied  { read } for  pid=19188 comm=rhsmcertd-worke name=container-tools.module dev="dm-0" ino=50331779 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0 
----
[...more unrelated rhsmcertd-worker denials...]
----
type=PROCTITLE msg=audit(04/13/2020 14:33:01.721:4700) : proctitle=/usr/libexec/platform-python /usr/libexec/rhsmcertd-worker 
type=SYSCALL msg=audit(04/13/2020 14:33:01.721:4700) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x55ff28cd93f0 a2=O_RDONLY a3=0x0 items=0 ppid=888 pid=21016 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rhsmcertd-worke exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null) 
type=AVC msg=audit(04/13/2020 14:33:01.721:4700) : avc:  denied  { read } for  pid=21016 comm=rhsmcertd-worke name=virt.module dev="dm-0" ino=50331781 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0 
----
type=PROCTITLE msg=audit(04/13/2020 18:22:25.219:4722) : proctitle=/usr/lib/systemd/systemd-makefs xfs /dev/sdb 
type=SYSCALL msg=audit(04/13/2020 18:22:25.219:4722) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7ffc62d97f3e a2=O_RDONLY|O_CLOEXEC a3=0x0 items=0 ppid=1 pid=22301 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-makefs exe=/usr/lib/systemd/systemd-makefs subj=system_u:system_r:init_t:s0 key=(null) 
type=AVC msg=audit(04/13/2020 18:22:25.219:4722) : avc:  denied  { read } for  pid=22301 comm=systemd-makefs name=sdb dev="devtmpfs" ino=40219776 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:nvme_device_t:s0 tclass=blk_file permissive=0 



My (limited) understanding is that, currently, this is expected behavior given that systemd-makefs is labeled as init_exec_t

# sesearch --allow -s init_t -t nvme_device_t
allow init_t device_node:blk_file { getattr relabelfrom relabelto };
allow init_t device_node:chr_file { create getattr relabelfrom relabelto };
allow init_t device_node:dir { getattr relabelfrom relabelto };
allow init_t device_node:fifo_file { getattr relabelfrom relabelto };
allow init_t device_node:file { getattr relabelfrom relabelto };
allow init_t device_node:lnk_file { getattr relabelfrom relabelto };
allow init_t device_node:sock_file { getattr relabelfrom relabelto };


# sesearch --allow -s fsadm_t -t nvme_device_t
allow devices_unconfined_type device_node:blk_file { append audit_access create execmod execute getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr swapon unlink write };
allow devices_unconfined_type device_node:chr_file { append audit_access create execute execute_no_trans getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr swapon unlink write };
allow devices_unconfined_type device_node:dir getattr;
allow devices_unconfined_type device_node:fifo_file getattr;
allow devices_unconfined_type device_node:file { append audit_access create execute execute_no_trans getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr swapon unlink write };
allow devices_unconfined_type device_node:lnk_file { append audit_access create execmod execute getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr swapon unlink write };
allow devices_unconfined_type device_node:sock_file getattr;
allow fsadm_t device_node:chr_file getattr;



But init_exec_t/init_t does have read access to other disk devices

# ls -lZ /dev/sda 
brw-rw----. 1 root disk system_u:object_r:fixed_disk_device_t:s0 8, 0 Mar  3 15:09 /dev/sda


# sesearch --allow -s init_t -t fixed_disk_device_t
allow init_t device_node:blk_file { getattr relabelfrom relabelto };
allow init_t device_node:chr_file { create getattr relabelfrom relabelto };
allow init_t device_node:dir { getattr relabelfrom relabelto };
allow init_t device_node:fifo_file { getattr relabelfrom relabelto };
allow init_t device_node:file { getattr relabelfrom relabelto };
allow init_t device_node:lnk_file { getattr relabelfrom relabelto };
allow init_t device_node:sock_file { getattr relabelfrom relabelto };
allow init_t fixed_disk_device_t:blk_file { append getattr ioctl lock open read write };
allow init_t fixed_disk_device_t:chr_file { append getattr ioctl lock open read write };
allow init_t fixed_disk_device_t:lnk_file { getattr read };


so maybe the policy needs to be fixed?

I was looking for something similar to the last AVC you attached. Thank you, Derrick.

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

Any ETA on this ?

Fix will be part of next minor release of RHEL.

Does this mean the fix will be part of next minor release in RHEL 7.x, 8.x and RHCOS 4.x as well ?

This fix should be a part of RHEL 8.3.

For RHEL 7, no bugzilla is currently open; given the fact the system is now in Maintenance Support 2 Phase, strong justification is needed to meet the criteria for inclusion.

For me in my environment, I've found I'm unable to use an NVMe device (/dev/nvme0n1) for the installation of OpenShift 4.5.  Upon initial boot RHCOS does indeed get written to the NVMe device, but the subsequent boot is where I observe ignition-ostree-mount-var.service exiting with a status=1/FAILURE, with systemd complaining about a Failure to start OSTree Prepare OS/.  

Repeating the same install on the same equipment but against a SATA based SSD for the root disk results in the install moving forward smoothly without issues.

I just tested this on a OCP 4.5 cluster. I see below errors still. This I believe is inline with what we were seeing few months ago

```
Sep 14 20:11:00 r192aw1.oss.labs systemd-makefs[2281]: Failed to probe "/dev/nvme1n1": Permission denied
Sep 14 20:11:00 r192aw1.oss.labs systemd[1]: systemd-mkfs: Main process exited, code=exited, status=1/FAILURE
Sep 14 20:11:00 r192aw1.oss.labs systemd[1]: systemd-mkfs: Failed with result 'exit-code'.
Sep 14 20:11:00 r192aw1.oss.labs systemd[1]: Failed to start Make File System on /dev/nvme1n1.
Sep 14 20:11:00 r192aw1.oss.labs kernel: audit: type=1400 audit(1600114260.292:4): avc:  denied  { read } for  pid=2281 comm="systemd-makefs" name="nvme1n1" dev="devtmpfs" ino=1379 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:nvme_device_t:s0 tclass=blk_file permissive=0
```

Upon checking the node and nvme1n1 disk, I see below selinux permissions

[root@r192aw1 ~]# ls -lZ /dev/nvme1n1
brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 1 Sep 14 20:10 /dev/nvme1n1

Attaching the machineconfig and machineconfigpool YAML files ..just FYI

Created attachment 1714850 [details]
Multi disk steps

I would like to know if the fix is already released or do we have to wait for some more time before we test this in OpenShift 4.5.x ?

(In reply to umesh_sunnapu from comment #21)
> I just tested this on a OCP 4.5 cluster. I see below errors still. This I
> believe is inline with what we were seeing few months ago

What version of selinux-policy* packages is installed on the machines, where you see the error?

(In reply to Milos Malik from comment #24)
> (In reply to umesh_sunnapu from comment #21)
> > I just tested this on a OCP 4.5 cluster. I see below errors still. This I
> > believe is inline with what we were seeing few months ago
> 
> What version of selinux-policy* packages is installed on the machines, where
> you see the error?

[root@r192aw1 ~]# rpm -qa | grep selinux-policy*
selinux-policy-3.14.3-41.el8_2.5.noarch
selinux-policy-targeted-3.14.3-41.el8_2.5.noarch

[root@r192aw1 ~]# cat /etc/system-release
Red Hat Enterprise Linux CoreOS release 4.5

Errors were seen when trying to use journalctl

[root@r192aw1 ~]# journalctl --since -60m -r | grep -i 'permission denied' -A 4 -B 2
Sep 14 20:56:20 r192aw1.oss.labs systemd[1]: systemd-mkfs: Failed with result 'exit-code'.
Sep 14 20:56:20 r192aw1.oss.labs systemd[1]: systemd-mkfs: Main process exited, code=exited, status=1/FAILURE
Sep 14 20:56:20 r192aw1.oss.labs systemd-makefs[9445]: Failed to probe "/dev/nvme1n1": Permission denied
Sep 14 20:56:20 r192aw1.oss.labs systemd[1]: kubelet.service: Consumed 141ms CPU time
Sep 14 20:56:20 r192aw1.oss.labs systemd[1]: Stopped MCO environment configuration.
Sep 14 20:56:20 r192aw1.oss.labs systemd[1]: Starting Make File System on /dev/nvme1n1...
Sep 14 20:56:20 r192aw1.oss.labs systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 163.

Let me know if you need any additional information.

According to changelog, the bug is fixed in selinux-policy-3.14.3-41.el8_2.6.

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