Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-10 08:05:07 UTC


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.