Bug 988046 - SELinux is preventing /usr/sbin/crond from 'search' accesses on the directory /etc/unbound.
SELinux is preventing /usr/sbin/crond from 'search' accesses on the directory...
Product: Fedora
Classification: Fedora
Component: unbound (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-24 11:21 EDT by Moez Roy
Modified: 2013-12-10 03:05 EST (History)
10 users (show)

See Also:
Fixed In Version: unbound-1.4.21-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-10 03:05:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Moez Roy 2013-07-24 11:21:16 EDT
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.
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


#============= crond_t ==============
allow crond_t named_conf_t:dir search;

audit2allow -R
require {
	type crond_t;

#============= crond_t ==============

Additional info:
reporter:       libreport-2.1.5
hashmarkername: setroubleshoot
kernel:         3.9.11-200.fc18.x86_64
type:           libreport
Comment 1 Daniel Walsh 2013-07-24 17:36:56 EDT
Any idea why crond would be searching /etc/unbound?
Comment 2 Moez Roy 2013-07-25 18:44:27 EDT
(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.
Comment 3 Tomas Mraz 2013-07-26 06:20:09 EDT
We would need a strace log showing the place where the crond does this. Maybe it could be done by some PAM module?
Comment 4 Daniel Walsh 2013-07-26 12:44:57 EDT
Paul is there something in dnssec which will trigger all apps that that do getpw to search /etc/unbound?
Comment 5 Paul Wouters 2013-07-26 14:03:13 EDT
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.
Comment 6 Daniel Walsh 2013-07-26 14:07:00 EDT
So why would crond be looking in this directory?
Comment 7 Moez Roy 2013-08-01 06:13:25 EDT
(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?
Comment 8 Moez Roy 2013-08-01 06:20:30 EDT
Can you also take a look at Bug 990971 and Bug 990974. Maybe it is related?
Comment 9 Miroslav Grepl 2013-08-02 04:40:16 EDT
So you have a cronjob which runs unbound-anchor, right?
Comment 10 Paul Wouters 2013-08-05 06:55:16 EDT
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
Comment 11 Daniel Walsh 2013-08-05 14:54:09 EDT
a9e8d3ce4ffa639a62a2875aed24b84d70107f10 fixes this in git.
Comment 12 Miroslav Grepl 2013-08-07 10:50:35 EDT
Back ported.

Note You need to log in before you can comment on or make changes to this bug.