After upgrading from Fedora 38 to 39, system logs are filled with SELinux errors similar to the following: `audit[1525]: AVC avc: denied { read } for pid=1525 comm="reader#1" name="b252:0" dev="tmpfs" ino=1077 scontext=system_u:system_r:collectd_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=0` pid 1525 is collectd setroubleshoot suggests the following: `ausearch -c 'reader#3' --raw | audit2allow -M my-reader3` which produces: `require { type collectd_t; type udev_var_run_t; class file read; }` It would appear that collectd_t is missing read permissions for files tagged udev_var_run_t Reproducible: Always Steps to Reproduce: 1. configure collectd on Fedora 38 2. upgrade to Fedora 39 Actual Results: setroubleshoot[14836]: SELinux is preventing reader#3 from read access on the file [x] Expected Results: No SELinux denies
Nothing has really changed here in collectd. Moving to selinux-policy for comment.
Hi, Can you please collect the denials with full auditing enabled? https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing
The output looks like this type=PROCTITLE msg=audit(11/13/2023 11:36:52.646:207) : proctitle=/usr/sbin/collectd type=PATH msg=audit(11/13/2023 11:36:52.646:207) : item=0 name=/run/udev/data/b259:0 inode=1253 dev=00:1a mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:udev_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/13/2023 11:36:52.646:207) : cwd=/var/lib/collectd type=SYSCALL msg=audit(11/13/2023 11:36:52.646:207) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7fd79ce6d850 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=1632 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=reader#0 exe=/usr/sbin/collectd subj=system_u:system_r:collectd_t:s0 key=(null) type=AVC msg=audit(11/13/2023 11:36:52.646:207) : avc: denied { read } for pid=1632 comm=reader#0 name=b259:0 dev="tmpfs" ino=1253 scontext=system_u:system_r:collectd_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=0 And a lot more, I just let the system run for a bit and let collectd do its thing. I can upload a full text file somewhere or a pastebin of the full output of `ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today` depending on which would be preferable.
Created attachment 1999175 [details] ausearch debug output
Thank you. You can now try the scratchbuild attached to this PR: https://github.com/fedora-selinux/selinux-policy/pull/1938
Thank you for the build. Installed it, and now SELinux is blocking on a different action. Re-enabled debugging and let it run for a bit.
Created attachment 2000959 [details] ausearch debug output 2
Thank you; collectd wants to read and write a block device, do you know why or what it is trying to do? Does some action fail because of this? type=PROCTITLE msg=audit(11/22/2023 14:01:33.902:296) : proctitle=/usr/sbin/collectd type=PATH msg=audit(11/22/2023 14:01:33.902:296) : item=0 name=/dev/nvme1n1 inode=511 dev=00:05 mode=block,660 ouid=root ogid=disk rdev=103:03 obj=system_u:object_r:fixed_disk_device_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/22/2023 14:01:33.902:296) : cwd=/var/lib/collectd type=SYSCALL msg=audit(11/22/2023 14:01:33.902:296) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7f727c0137d0 a2=O_RDWR a3=0x0 items=1 ppid=1 pid=1598 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=reader#4 exe=/usr/sbin/collectd subj=system_u:system_r:collectd_t:s0 key=(null) type=AVC msg=audit(11/22/2023 14:01:33.902:296) : avc: denied { read write } for pid=1598 comm=reader#4 name=nvme1n1 dev="devtmpfs" ino=511 scontext=system_u:system_r:collectd_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 ----
I think I've tracked down the RW issue, it was the smart plugin that reads SMART data from disks. Now, it's failing to do that because it's trying to open the block file RW and I don't see that there's any reason for it to do so. It does need read, but I'll follow up with the collectd project to see why it's requesting RW permissions. We can probably close this bug report now, the fix provided in comment 5 solved the initial issue and this latest one is on the collectd side.
Switching the component. Collectd folks, why collectd want to open /dev/nvme1n1 with O_RDWR?
I have no idea why it's doing that. Upstream the entire plugin was imported with that O_RDWR in it... so not sure the history.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.