CentOS

As I've finally had a chance to peek into var/log/messages I found plenty of similar errors to this one:

Jul 28 12:22:32 dualxeon setroubleshoot: SELinux is preventing /usr/bin/find from using the dac_read_search capability. For complete SELinux messages. run sealert -l d5aa810c-8646-4aec-8f25-2d002f719f6c
Jul 28 12:22:32 dualxeon python: SELinux is preventing /usr/bin/find from using the dac_read_search capability.#012#012***** Plugin dac_override (91.4 confidence) suggests **********************#012#012If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system#012Then turn on full auditing to get path information about the offending file and generate the error again.#012Do#012#012Turn on full auditing#012# auditctl -w /etc/shadow -p w#012Try to recreate AVC. Then execute#012# ausearch -m avc -ts recent#012If you see PATH record check ownership/permissions on file, and fix it,#012otherwise report as a bugzilla.#012#012***** Plugin catchall (9.59 confidence) suggests **************************#012#012If you believe that find should have the dac_read_search capability by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'find' --raw | audit2allow -M my-find#012# semodule -i my-find.pp#012

Is it anything I should worry about? How to fix it - would using the command suggested in the log be a good idea?

I have them too after upgrading my kernel vom 3.10 to 4.15. Found this too as fixed issues in the bugtracker. I dont know what to do.

The supported CentOS 7 kernel is 3.10 - currently 3.10.0-693.21.1.el7. If you update to newer ones from other sources then you get to keep all the pieces if it breaks.

When you use an out-of-tree kernel, then you can anticipate seeing conflicts between userland tools and the kernel. Later lkml.org kernels (current mainline = 4.16) trigger dac_read_search selinux denials when used in EL7. I view dac_read_search to be relatively harmless.

You can generate local selinux policy to address the denials as suggested in the log output in post #1 or by following wiki.centos.org/HowTos/SELinux suggestions. The policy might look something like this:

Code: Select all

module localdacreadsearch 1.0;

require {
	type accountsd_t;
	type automount_t;
	type chkpwd_t;
	type cupsd_config_t;
	type mdadm_t;
	type nut_upsdrvctl_t;
	type nut_upsd_t;
	type nut_upsmon_t;
	type postfix_master_t;
	type rpcd_t;
	type spamd_t;
	type systemd_logind_t;
	type systemd_tmpfiles_t;
	type useradd_t;
	class capability dac_read_search;
}

allow accountsd_t self:capability dac_read_search;
allow automount_t self:capability dac_read_search;
allow chkpwd_t self:capability dac_read_search;
allow cupsd_config_t self:capability dac_read_search;
allow mdadm_t self:capability dac_read_search;
allow nut_upsdrvctl_t self:capability dac_read_search;
allow nut_upsd_t self:capability dac_read_search;
allow nut_upsmon_t self:capability dac_read_search;
allow postfix_master_t self:capability dac_read_search;
allow rpcd_t self:capability dac_read_search;
allow spamd_t self:capability dac_read_search;
allow systemd_logind_t self:capability dac_read_search;
allow systemd_tmpfiles_t self:capability dac_read_search;
allow useradd_t self:capability dac_read_search;

As TrevorH suggested, when you use out-of-tree code, then you are responsible for picking up the broken pieces.

CentOS

dac_read errors in the logs

dac_read errors in the logs

Re: dac_read errors in the logs

Re: dac_read errors in the logs

Re: dac_read errors in the logs