Description of problem: SELinux is preventing zabbix_agentd from 'getattr' accesses on the file /proc/kcore. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that zabbix_agentd should be allowed getattr access on the kcore file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'zabbix_agentd' --raw | audit2allow -M my-zabbixagentd # semodule -X 300 -i my-zabbixagentd.pp Additional Information: Source Context system_u:system_r:zabbix_agent_t:s0 Target Context system_u:object_r:proc_kcore_t:s0 Target Objects /proc/kcore [ file ] Source zabbix_agentd Source Path zabbix_agentd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.19-1.fc37.noarch Local Policy RPM zabbix-selinux-6.0.8-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.1.11-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb 9 19:20:24 UTC 2023 x86_64 x86_64 Alert Count 6 First Seen 2023-02-15 20:44:35 GMT Last Seen 2023-02-16 19:44:35 GMT Local ID a7f07d90-52c4-48bf-b944-2dbf3b82932b Raw Audit Messages type=AVC msg=audit(1676576675.836:523): avc: denied { getattr } for pid=5913 comm="zabbix_agentd" path="/proc/kcore" dev="proc" ino=4026532075 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file permissive=0 Hash: zabbix_agentd,zabbix_agent_t,proc_kcore_t,file,getattr Version-Release number of selected component: selinux-policy-targeted-37.19-1.fc37.noarch Additional info: component: zabbix reporter: libreport-2.17.4 hashmarkername: setroubleshoot kernel: 6.1.11-200.fc37.x86_64 type: libreport
Interesting coincidence, I just came across this and two other os EL8: type=AVC msg=audit(1676601007.615:895): avc: denied { getattr } for pid=39084 comm="zabbix_agentd" path="/run/initctl" dev="tmpfs" ino=19546 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file permissive=1 type=AVC msg=audit(1676601007.615:896): avc: denied { getattr } for pid=39084 comm="zabbix_agentd" path="/run/systemd/journal/dev-log" dev="tmpfs" ino=12722 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:devlog_t:s0 tclass=sock_file permissive=1 type=AVC msg=audit(1676601007.616:897): avc: denied { getattr } for pid=39084 comm="zabbix_agentd" path="/proc/kcore" dev="proc" ino=4026532029 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file permissive=1 It seems to happen on service start. It also seems to be related to systemd or similar process start as I can't reproduce with strace. Bringing in the SELinux folks for their opinion. I suspect we just need some dontaudit rules, but not sure. FWiW - I'm not able to reproduce with stock zabbix-agent package on my rawhide VM.
Actually, I think I'm seeing these every hour. Probably related to the vfs.dev.discovery checks, but not sure.
*** Bug 2170953 has been marked as a duplicate of this bug. ***
Moving back to zabbix, but comments from the Fedora SELinux team would be greatly appreciated.
Similar problem has been detected: Booted the machine. Logged in. Started the service with: "sudo systemctl restart zabbix-agent.service zabbix-server-mysql.service". hashmarkername: setroubleshoot kernel: 6.2.8-200.fc37.x86_64 package: selinux-policy-targeted-37.19-1.fc37.noarch reason: SELinux is preventing zabbix_agentd from 'getattr' accesses on the file /proc/kcore. type: libreport
Off the audit records we can see stat() or a similar syscall is run for 3 files. I am afraid a zabbix developer is required to answer if the access requests are legitimate. If yes, then if it should be only the getattr permission or also some additional ones, like actually using the journal socket. If not, if it is expected to get attributes of other filesystem objects. A reproducer using common scenarios would be helpful. With full auditing enabled, more information can be gathered by auditd.
Steps to reproduce: 1. dnf install zabbix-agent 2. systemctl start zabbix-agent 3. Find the listener process: ps -fu zabbix | grep listener 4. strace -fp PID1 -p PID2 -p PID3 -e newfstatat 5. zabbix_get -s 127.0.0.1 -k vfs.dev.discovery You'll see that the agent is simply enumerating everything in /dev/ and failing on: [pid 1269] newfstatat(AT_FDCWD, "/dev/core", 0x7ffc3c26e480, 0) = -1 EACCES (Permission denied) [pid 1269] newfstatat(AT_FDCWD, "/dev/log", 0x7ffc3c26e480, 0) = -1 EACCES (Permission denied) [pid 1269] newfstatat(AT_FDCWD, "/dev/initctl", 0x7ffc3c26e480, 0) = -1 EACCES (Permission denied) # ls -l /dev/core /dev/log /dev/initctl lrwxrwxrwx. 1 root root 11 Oct 28 14:49 /dev/core -> /proc/kcore lrwxrwxrwx. 1 root root 12 Oct 28 14:49 /dev/initctl -> /run/initctl lrwxrwxrwx. 1 root root 28 Oct 28 14:49 /dev/log -> /run/systemd/journal/dev-log So at least it this place it seem like a good use of dontaudit rules (which I will need to research). It probably would be good if upstream simply skipped those...
Zdenek - Thanks for you response. I've tried to add dontaudit rules here: https://src.fedoraproject.org/rpms/zabbix/pull-request/9 but it doesn't seem to be working. It adds: # These are triggered by vfs.dev.discovery enumerating everyting in /dev type devlog_t; dontaudit zabbix_agent_t devlog_t:sock_file getattr; init_dontaudit_getattr_initctl(zabbix_agent_t) kernel_dontaudit_getattr_core_if(zabbix_agent_t) Can you see what I'm doing wrong? Thanks.
I'm seeing this on install: Re-declaration of type devlog_t Previous declaration of type at /var/lib/selinux/targeted/tmp/modules/200/zabbix/cil:31 Bad type declaration at /var/lib/selinux/targeted/tmp/modules/200/zabbix/cil:31 Failed to build AST /usr/sbin/semodule: Failed! Ah, I think this needs to be: gen_require(` type devlog_t; ')
FEDORA-2023-589302cd35 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-589302cd35
FEDORA-EPEL-2023-5b86de9695 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5b86de9695
FEDORA-2023-9fc728735d has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-9fc728735d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9fc728735d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-bdb43a23da has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-bdb43a23da` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-bdb43a23da See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-589302cd35 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-589302cd35` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-589302cd35 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-5b86de9695 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5b86de9695 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Orion, looks generally good. A new interface in selinux-policy would be needed if you wanted to have also the devlog issue addressed in a more appropriate way.
FEDORA-2023-9fc728735d has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-589302cd35 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-bdb43a23da has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-5b86de9695 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.