Bug 2170630

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.