Red Hat Bugzilla – Bug 988046
SELinux is preventing /usr/sbin/crond from 'search' accesses on the directory /etc/unbound.
Last modified: 2013-12-10 03:05:07 EST
Description of problem: SELinux is preventing /usr/sbin/crond from 'search' accesses on the directory /etc/unbound. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that crond should be allowed search access on the unbound directory 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: # grep crond /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:crond_t:s0-s0:c0.c1023 Target Context system_u:object_r:named_conf_t:s0 Target Objects /etc/unbound [ dir ] Source crond Source Path /usr/sbin/crond Port <Unknown> Host (removed) Source RPM Packages cronie-1.4.10-1.fc18.x86_64 Target RPM Packages unbound-libs-1.4.20-3.fc18.x86_64 Policy RPM selinux-policy-3.11.1-98.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.9.8-200.fc18.x86_64 #1 SMP Fri Jun 28 14:45:36 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-07-01 03:10:01 PDT Last Seen 2013-07-01 03:10:01 PDT Local ID c4a5c6e3-accd-4dc7-89c1-496568848319 Raw Audit Messages type=AVC msg=audit(1372673401.765:340): avc: denied { search } for pid=4530 comm="crond" name="unbound" dev="dm-0" ino=3016666 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir type=SYSCALL msg=audit(1372673401.765:340): arch=x86_64 syscall=chdir success=no exit=EACCES a0=7f8d6eb6d475 a1=0 a2=7f8d6ccba416 a3=4000 items=0 ppid=4528 pid=4530 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 ses=7 tty=(none) comm=crond exe=/usr/sbin/crond subj=system_u:system_r:crond_t:s0-s0:c0.c1023 key=(null) Hash: crond,crond_t,named_conf_t,dir,search audit2allow #============= crond_t ============== allow crond_t named_conf_t:dir search; audit2allow -R require { type crond_t; } #============= crond_t ============== bind_read_config(crond_t) Additional info: reporter: libreport-2.1.5 hashmarkername: setroubleshoot kernel: 3.9.11-200.fc18.x86_64 type: libreport
Any idea why crond would be searching /etc/unbound?
(In reply to Daniel Walsh from comment #1) > Any idea why crond would be searching /etc/unbound? I have no idea. But I do have the program DNNSSEC Trigger which in theory is supposed to resolve all DNS queries using SSL instead of the default UDP Port 53.
We would need a strace log showing the place where the crond does this. Maybe it could be done by some PAM module?
Paul is there something in dnssec which will trigger all apps that that do getpw to search /etc/unbound?
Applications that do not link against libunbound should not cause anything - all they do is dns lookups. applications that link against libunbound likely use /etc/unbound/ config files, for instance to setup POSIX expected "/etc/hosts before DNS" behaviour. Note that libunbound (the package) does have a cron job to check for the DNSSEC root key. dnssec-trigger does not send all DNS queries using SSL instead of UDP 53. It _only_ does that as a method of last resort if UDP 53, TCP 53 and TCP 80 does not get out for DNS queries _and_ the DHCP obtained DNS forwarders are broken.
So why would crond be looking in this directory?
(In reply to Tomas Mraz from comment #3) > We would need a strace log showing the place where the crond does this. > Maybe it could be done by some PAM module? I just got the AVC alert again. Where do I find this strace log file?
Can you also take a look at Bug 990971 and Bug 990974. Maybe it is related?
So you have a cronjob which runs unbound-anchor, right?
Correct, the cron job is: # Look to see if the DNSSEC Root key got rolled, if so check trust and update 10 3 1 * * unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.anchor -c /etc/unbound/icannbundle.pem
a9e8d3ce4ffa639a62a2875aed24b84d70107f10 fixes this in git.
Back ported.