Bug 2249257 - Missing SELinux permissions for collectd
Summary: Missing SELinux permissions for collectd
Alias: None
Product: Fedora
Classification: Fedora
Component: collectd
Version: 39
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ruben Kerkhof
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2023-11-11 18:11 UTC by mhurron
Modified: 2024-01-24 21:09 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: ---

Attachments (Terms of Use)
ausearch debug output (1.52 MB, text/plain)
2023-11-13 20:31 UTC, mhurron
no flags Details
ausearch debug output 2 (149.23 KB, text/plain)
2023-11-22 20:12 UTC, mhurron
no flags Details

Description mhurron 2023-11-11 18:11:55 UTC
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

Comment 1 Kevin Fenzi 2023-11-11 19:25:51 UTC
Nothing has really changed here in collectd. Moving to selinux-policy for comment.

Comment 2 Zdenek Pytela 2023-11-13 08:38:37 UTC

Can you please collect the denials with full auditing enabled?


Comment 3 mhurron 2023-11-13 20:02:57 UTC
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.

Comment 4 mhurron 2023-11-13 20:31:04 UTC
Created attachment 1999175 [details]
ausearch debug output

Comment 5 Zdenek Pytela 2023-11-15 10:18:38 UTC
Thank you. You can now try the scratchbuild attached to this PR:

Comment 6 mhurron 2023-11-22 20:11:29 UTC
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.

Comment 7 mhurron 2023-11-22 20:12:15 UTC
Created attachment 2000959 [details]
ausearch debug output 2

Comment 8 Zdenek Pytela 2023-11-23 11:16:48 UTC
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 

Comment 9 mhurron 2023-11-25 23:03:17 UTC
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.

Comment 10 Zdenek Pytela 2023-11-27 07:54:03 UTC
Switching the component.
Collectd folks, why collectd want to open /dev/nvme1n1 with O_RDWR?

Comment 11 Kevin Fenzi 2023-12-17 23:30:22 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.