Bug 988046 - SELinux is preventing /usr/sbin/crond from 'search' accesses on the directory /etc/unbound.
Summary: SELinux is preventing /usr/sbin/crond from 'search' accesses on the directory...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:5f5c022461b48fb7d9632141bf0...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-24 15:21 UTC by Moez Roy
Modified: 2013-12-10 08:05 UTC (History)
10 users (show)

Fixed In Version: unbound-1.4.21-1.fc18
Clone Of:
Environment:
Last Closed: 2013-12-10 08:05:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Moez Roy 2013-07-24 15:21:16 UTC
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

Comment 1 Daniel Walsh 2013-07-24 21:36:56 UTC
Any idea why crond would be searching /etc/unbound?

Comment 2 Moez Roy 2013-07-25 22:44:27 UTC
(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 10:20:09 UTC
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 16:44:57 UTC
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 18:03:13 UTC
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 18:07:00 UTC
So why would crond be looking in this directory?

Comment 7 Moez Roy 2013-08-01 10:13:25 UTC
(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 10:20:30 UTC
Can you also take a look at Bug 990971 and Bug 990974. Maybe it is related?

Comment 9 Miroslav Grepl 2013-08-02 08:40:16 UTC
So you have a cronjob which runs unbound-anchor, right?

Comment 10 Paul Wouters 2013-08-05 10:55:16 UTC
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 18:54:09 UTC
a9e8d3ce4ffa639a62a2875aed24b84d70107f10 fixes this in git.

Comment 12 Miroslav Grepl 2013-08-07 14:50:35 UTC
Back ported.


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