Note that I've verified this issue only for Zabbix Agent, but according to other user reports this affects most/all Zabbix products.
FYI, installing the following SELinux module fixed the issue for Zabbix Agent:
module zabbix_agent_setrlimit 1.0;
require {
type zabbix_agent_t;
class process setrlimit;
}
#============= zabbix_agent_t ==============
allow zabbix_agent_t self:process setrlimit;
A similar SELinux module should be provided for every Zabbix product and automatically be installed/activated.
workaround centos 7.3
- yum install policycoreutils-python
server:
cat /var/log/audit/audit.log | grep zabbix_agentd | grep denied | audit2allow -M zabbix_agent_setrlimit
semodule -i zabbix_agent_setrlimit.pp
agent:
cat /var/log/audit/audit.log | grep zabbix_server | grep denied | audit2allow -M zabbix_server_setrlimit
semodule -i zabbix_server_setrlimit.pp
@agris: This isn't really helpful. This ticket is NOT about workarounds, but instead about a real solution. Workarounds have already been posted in one of the linked issues.
Here is another thing the policy should cover:
SELinux keeps zabbix server from killing external scripts that have been running too long.
That's what happens:
[root@zabbix ~]# fgrep 'failed to kill' /var/log/zabbix/zabbix_server.log | tail -1 89866:20170117:054115.944 failed to kill [/usr/lib/zabbix/externalscripts/cellinfo2 "10.10.10.10" "LTESINR"]: [13] Permission denied [root@zabbix ~]# cat /var/log/audit/audit.log | grep zabbix | grep denied | tail -1 type=AVC msg=audit(1484660309.035:83396): avc: denied { signal } for pid=89863 comm="zabbix_server" scontext=system_u:system_r:zabbix_t:s0 tcontext=system_u:system_r:zabbix_script_t:s0 tclass=process
And here is what a zabbix policy would have to allow:
[root@zabbix ~]# cat /var/log/audit/audit.log | grep zabbix | grep denied | tail -1 | audit2allow
#============= zabbix_t ==============
allow zabbix_t zabbix_script_t:process signal;
Proposed patch to upstream refpolicy for the setrlimit call: http://oss.tresys.com/pipermail/refpolicy/2017-May/009635.html
@stefan.radman I've created a PR against the Fedora policy for your issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/13 - unfortunatly the zabbix_scripts_t types are not ported to upstreams refpolicy.
refpolicy setrlimit patch was merged: https://github.com/TresysTechnology/refpolicy-contrib/commit/9fbf1b94fa4e9f6936ea7100f606ac572ed7af95
First post, so hopefully this is the right issue to mention this. I found this issue because an enforcing selinux was causing the zabbix PID file not to be written, and it's somehow linked with this bug.
Using the latest Centos 7.3 and the latest zabbix 3.2 repo (3.2.6), I also noticed that the latest zabbix-server.service file at /usr/lib/systemd/system/zabbix-server.service still has the PIDFile variable pointing at /run/zabbix/zabbix_server.pid and not /var/run/zabbix/zabbix_server.pid
Not sure if this makes a difference, but it's wrong and needs fixing too.
Nayphee /run is the new /var/run with systemd. so /run/zabbix/zabbix_server.pid seems not wrong. On Fedora 25 I get correct zabbix_var_run for this path:
$ matchpathcon /run/zabbix/zabbix_server.pid /run/zabbix/zabbix_server.pid system_u:object_r:zabbix_var_run_t:s0
Oh OK... I noticed that /var/run is a link to /run
Either way, the default zabbix server config file and the zabbix-server.service file can't agree whether to use /var/run or just /run 
If I set SELinux to Permissive, the PID writing issues go away - and looking at the audit.log, setrlimit is causing it pain. Hope to see the fix released soon.
Nayphee The SELinux fix will be included in CentOS/RHEL 7.4.
I have this issue:
[root@v101 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
#============= zabbix_agent_t ==============
allow zabbix_agent_t self:capability { dac_override dac_read_search };
Oct 20 09:24:52 v101.thecamels zabbix_agentd[6887]: zabbix_agentd [6887]: /etc/zabbix/zabbix_agentd.conf.d: [13] Permission denied
[root@v101 ~]# ls -lZ /etc/zabbix/zabbix_agentd.conf.d
-rw-------. zabbix zabbix system_u:object_r:etc_t:s0 amavis.conf
-rw-------. zabbix zabbix system_u:object_r:etc_t:s0 audit.conf
-rw-------. zabbix zabbix system_u:object_r:etc_t:s0 bind.conf
Also additional info:
-rwxr-xr-x. root root system_u:object_r:unconfined_exec_t:s0 /usr/sbin/zabbix_agentd
I can run agent as user from cli, but not starting from systemd.
@Kamil, your agent binary has the wrong security context (unconfined_exec).
Mine looks like this.
[root@dev7 ~]# ls -lZ /usr/sbin/zabbix_agentd -rwxr-xr-x. root root system_u:object_r:zabbix_agent_exec_t:s0 /usr/sbin/zabbix_agentd [root@dev7 ~]# rpm -qf /usr/sbin/zabbix_agentd zabbix-agent-3.0.12-1.el7.x86_64 [root@dev7 ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core)
Did you install from RPM? Does it help to restore the default security context?
[root@dev7 ~]# restorecon -v /usr/sbin/zabbix_agentd restorecon reset /usr/sbin/zabbix_agentd context system_u:object_r:unconfined_exec_t:s0->system_u:object_r:zabbix_agent_exec_t:s0
Yes I know. It should work with this context (it is outside SELinux) but in that case systemd can't start process. With normal context there is problem that I have pasted ealier.