We are getting constant SELinux AVC denied logs for snmpd & chronyd but no changes in SELinux policy. Also the issue is happening on few set of servers only & not for other set of servers despite they are same in terms of configuration i.e. SELinux policy and all.
can someone pls help.
If there are denials, then there should be stuff logged which would tell you how to fix it. Tools like sealert can be used or even the following ones:
audit2why -a
audit2allow -a
based on the output it should give you hints on what you need to do. Unfortunately, your post doesn’t give any details such as this so impossible to say how to fix it until you post such results.
thanks for response. Aware about audit2why & audit2allow but trying to find out what triggered it all of sudden that we started to see such denials all of sudden without any changes in policy & happening on few servers only. We even tried restorecon but not helped
Using the tools you should find out why a violation has occured and info on how to fix it. Again, without you posting the output of those commands, it’s going to be impossible for anyone here to help. If you want help you need to provide a lot more info than what you have done so far.
Getting below avc denied errors
): avc: denied { write } for pid=001256 comm=“chronyc” name=“chrony” dev=“tmpfs” ino=568964 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:chronyd_var_run_t:s0 tclass=dir permissive=1
avc: denied { remove_name } for pid=7274544 comm=“chronyc” name=“chronyc.7274544.sock” dev=“tmpfs” ino=781616 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:chronyd_var_run_t:s0 tclass=dir permissive=1
Audit2allow -a o/p as below
audit2why stating was caused by Missing Type Enforcement rules.
But would like to know how issue started all of sudden no policy level changes made on server.
also policy & context are same on Impacted & non impacted server.
I can understand your wanting to know why this started. Have you looked in yum history to see whether any packages were changed (e.g. by auto update) ? And have you compared the total list of installed packages on impacted and non-impacted servers ? If packages are different, it’s possible that a different version of a package is trying to do something that a previous version wasn’t trying to do.
And when you say that no policy changes have been made, have you compared the contents of /etc/selinux on impacted and non-impacted using diff -r ? Likewise /var/lib/selinux ?
If none of that shows any differences, and you’ve run a full relabel by putting -F in a file /.autorelabel and rebooting, then I’d agree that it’s rather odd.
Are you knowingly running snmp(d) on all affected servers?
sure let me check for this aspect again.
yes its running on all servers affected & non-affected server for monitoring purpose.
From output of audit2allow, it looks like snmpd is talking to chronyd on its control socket via UDP. It looks as if snmpd is collecting data from chrony (e.g. stratum data, drift, etc) for monitoring purposes.
Selinux policies out of the box handle default configurations for services, but cannot describe all possible (optional) interactions between services.
OK, how did you originally install it, and enable snmp(d)?
yes snmpd is talking to chronyd & collecting data collecting data from chrony for monitoring purposes.
We have this configured in snmpd.conf:
exec ntp_jitter /bin/bash /bin/ntp_jitter.sh
This scripts run the command
chronyc tracking |grep ‘Root dispersion’ |awk ‘{print $4*1000}’
So the avc denied occurs when this is script is run by snmp.
Is this because snmpd is not allowed to execute chronyc command?
Okay, smtpd uses chroncyc to talk to chronyd. AFAIK, chronyc talks to chronyd via its control socket.
Is this because snmpd is not allowed to execute chronyc command?
Snmpd is not forbidden from executing chronyc, but chronyc inherits the selinux context of snmp (because out-of-the-box selinux policies do not define a transition from snmpd_t to chrony_c).
Consequently, chronyc is executing under snmpd_t context, which is not allowed from sending to chronyd’s control socket, hence the AVC denials.
You can apply the policy additions suggested by audit2allow, or you could check how to add the transitions necessary for chronyc to run under its native context when executed from snmpd.
