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 1066149 - dnscache no longer starts in enforcing mode (targeted)
Summary: dnscache no longer starts in enforcing mode (targeted)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-17 20:25 UTC by Bruno Wolff III
Modified: 2014-11-19 14:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-19 14:44:52 UTC


Attachments (Terms of Use)

Description Bruno Wolff III 2014-02-17 20:25:50 UTC
Description of problem:
After a recent selinux-policy update, dsncache did not start after a reboot until I switched to permissive mode. (Then systemctl restart dnscache fixed the issue.)

Version-Release number of selected component (if applicable):

selinux-policy-3.13.1-24.fc21

Additional info:
type=SYSCALL msg=audit(1392668209.774:327): arch=c000003e syscall=49 success=yes exit=0 a0=5 a1=7ffff7e97c00 a2=10 a3=7ffff7e97bfc items=0 ppid=1 pid=4396 auid=4294967295 uid=2 gid=2 euid=2 suid=2 fsuid=2 egid=2 sgid=2 fsgid=2 tty=(none) ses=4294967295 comm="dnscache" exe="/usr/sbin/dnscache" subj=system_u:system_r:init_t:s0 key=(null)

Comment 1 Bruno Wolff III 2014-02-17 20:27:45 UTC
Sorry, that was the wrong log entry. This one indicates the problem:
type=AVC msg=audit(1392668173.397:318): avc:  denied  { listen } for  pid=4396 comm="dnscache" laddr=127.0.0.1 lport=53 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=tcp_socket

Comment 2 Bruno Wolff III 2014-02-17 20:29:17 UTC
And this one (which is different than the one above):
type=AVC msg=audit(1392668173.359:317): avc:  denied  { name_bind } for  pid=4396 comm="dnscache" src=53 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dns_port_t:s0 tclass=tcp_socket

Comment 3 Miroslav Grepl 2014-02-18 11:00:20 UTC
Probably labeling issue. What does

# ps -efZ |grep init_t

Comment 4 Bruno Wolff III 2014-02-18 12:30:13 UTC
ps -efZ |grep init_t
system_u:system_r:init_t:s0     root         1     0  0 Feb17 ?        00:00:12 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
system_u:system_r:init_t:s0     bruno     1457     1  0 Feb17 ?        00:00:00 /usr/lib/systemd/systemd --user
system_u:system_r:init_t:s0     bruno     1460  1457  0 Feb17 ?        00:00:00 (sd-pam)
system_u:system_r:init_t:s0     daemon    4583     1  0 Feb17 ?        00:00:00 /usr/sbin/dnscache
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 11298 11079  0 06:28 pts/6 00:00:00 grep --color=auto init_t

Comment 5 Bruno Wolff III 2014-02-18 12:31:57 UTC
I had done a relabel with restorecon after seeing the issue, but didn't do another reboot. I'll try one later today.

Comment 6 Daniel Walsh 2014-02-21 20:54:48 UTC
Miroslav these are caused by the bug that disables unconfined_domain(init_t)  Which is fixed in selinux-policy-3.13.1-26.fc21.

But we really should label all of this content, perhaps as bind_exec_t?

Comment 7 Miroslav Grepl 2014-03-03 12:03:26 UTC
(In reply to Daniel Walsh from comment #6)
> Miroslav these are caused by the bug that disables unconfined_domain(init_t)
> Which is fixed in selinux-policy-3.13.1-26.fc21.
> 
> But we really should label all of this content, perhaps as bind_exec_t?

Yes. This is not only about BIND. We could see these issues also for others.


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