Bug 1147705

*** Bug 1147704 has been marked as a duplicate of this bug. ***

*** Bug 1147608 has been marked as a duplicate of this bug. ***

commit 5dee492b238b1882272261e7ffd23a515d38689d
Author: Miroslav Grepl <mgrepl>
Date:   Mon Oct 13 16:06:24 2014 +0200

    Allow dnssec_trigger_t to execute unbound-control in own domain

Add to rawhide/f21/f20.

selinux-policy-3.13.1-86.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-86.fc21

Package selinux-policy-3.13.1-86.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-86.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12863/selinux-policy-3.13.1-86.fc21
then log in and leave karma (feedback).

selinux-policy-3.13.1-88.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-88.fc21

selinux-policy-3.13.1-90.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Note that, although they were both closed as duplicates of this bug, the bug #1158117 is about Fedora 20, and the bug #1147608 is about Rawhide.

Description of problem:
Just using dnssec-trigger. 

Version-Release number of selected component:
selinux-policy-3.13.1-89.fc22.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.18.0-0.rc2.git3.1.fc22.x86_64
type:           libreport

Yeah, please fix also rawhide/f20. ;)

Description of problem:
I don't know what triggers this, however I think unbound-control should NOT touch /run/dnssec-trigger/lock

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.16.6-203.fc20.x86_64
type:           libreport

Tomas,
what is the current issue?

I think ABRT messed things up.

SELinux is preventing /usr/sbin/unbound-control from write access on the file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore unbound-control trying to write access the  file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/unbound-control /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that unbound-control should be allowed write access on the  file 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 unbound-control /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:named_t:s0
Target Context                system_u:object_r:dnssec_trigger_var_run_t:s0
Target Objects                 [ file ]
Source                        unbound-control
Source Path                   /usr/sbin/unbound-control
Port                          <Unknown>
Host                          thozza-pc
Source RPM Packages           unbound-1.4.22-5.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-192.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     thozza-pc
Platform                      Linux thozza-pc 3.16.6-203.fc20.x86_64 #1 SMP Sat
                              Oct 25 12:44:32 UTC 2014 x86_64 x86_64
Alert Count                   781
First Seen                    2014-10-24 18:25:03 CEST
Last Seen                     2014-11-03 12:27:47 CET
Local ID                      d6663554-e5b2-4fd0-9d4a-aee1171524e1

Raw Audit Messages
type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for  pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs" ino=21425 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:dnssec_trigger_var_run_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1415014067.263:706): arch=x86_64 syscall=execve success=yes exit=0 a0=1166740 a1=11687b0 a2=e06d00 a3=0 items=0 ppid=19075 pid=19110 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=unbound-control exe=/usr/sbin/unbound-control subj=system_u:system_r:named_t:s0 key=(null)

Hash: unbound-control,named_t,dnssec_trigger_var_run_t,file,write

however I wanted to file an unbound bug... I think unbound-control should not touch the file it tries to.

*** Bug 1159347 has been marked as a duplicate of this bug. ***

I added guys from unbound,

Guys what do you think about this AVC? 

Thank you for help!

I've seen this message before on F20. It's seems like a glitch in SELinux policy, which prevents unbound-control from writing to /run/dnssec-trigger/lock.

---
type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for  pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs" ino=21425 
---


The log message suggests overriding the policy by

---
If you want to ignore unbound-control trying to write access the  file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do

# grep /usr/sbin/unbound-control /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp
---

It seems to fix the annoying abrt popup.

(In reply to pjp from comment #16)
> I've seen this message before on F20. It's seems like a glitch in SELinux
> policy, which prevents unbound-control from writing to
> /run/dnssec-trigger/lock.

Hi PJP.

I don't see any reason why should unbound-control touch /run/dnssec-trigger/lock. This needs more investigation on unbound side!

Well it looks like a leak from dnssec_trigger.

type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for  pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs" ino=21425 

on EXEC.

Description of problem:
After applying updates, rebooting, and logging in this SELinux alert appeared.  I am using dnssec-trigger/unbound.

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.17.2-200.fc20.x86_64
type:           libreport

*** Bug 1167134 has been marked as a duplicate of this bug. ***

(In reply to Miroslav Grepl from comment #18)
> Well it looks like a leak from dnssec_trigger.

More specifically dnssec-trigger-script written in Python.

> type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for 
> pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs"
> ino=21425 
> 
> on EXEC.

Erm... this looks like the way to go:

diff --git a/dnssec-trigger-script.in b/dnssec-trigger-script.in
index 70066cb..a0aab2e 100644
--- a/dnssec-trigger-script.in
+++ b/dnssec-trigger-script.in
@@ -10,6 +10,10 @@ import os, sys, fcntl, shutil, glob, subprocess
 import logging, logging.handlers
 import socket, struct
 
+# Python compatibility stuff
+if not hasattr(os, "O_CLOEXEC"):
+    os.O_CLOEXEC = 0x80000
+
 DEVNULL = open("/dev/null", "wb")
 
 log = logging.getLogger()
@@ -33,7 +37,7 @@ class Lock:
         dirname = os.path.dirname(self.path)
         if not os.path.exists(dirname):
             os.makedirs(dirname)
-        self.lock = open(self.path, "w")
+        self.lock = os.open(self.path, os.O_WRONLY|os.O_CLOEXEC)
 
     def __enter__(self):
         fcntl.lockf(self.lock, fcntl.LOCK_EX)

Description of problem:
Joined wireless network with staff_u user. 

Version-Release number of selected component:
selinux-policy-3.13.1-92.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.3-300.fc21.x86_64
type:           libreport

Description of problem:
I installed and enabled unbound and dnssec-trigger, rebooted, then connected to OpenVPN via NetworkManager.

Version-Release number of selected component:
selinux-policy-3.13.1-99.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.4-301.fc21.x86_64
type:           libreport

Description of problem:
1. I just rebooted, after installing a new kernel.
2. Before the reboot, using nm-connection-editor, I had set NetworkManager to connect to my VPN after connecting to the local WiFi.

Version-Release number of selected component:
selinux-policy-3.13.1-99.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.6-300.fc21.x86_64
type:           libreport

Description of problem:
Happens when resuming from sleep.

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.7-300.fc21.x86_64
type:           libreport

Description of problem:
Nothing, it just popped up by itself.  dnssec-trigger/unbound is running.  I did recently edit /etc/unbound/unbound.conf to set verbosity=1 and systemctl restart unbound.

Version-Release number of selected component:
selinux-policy-3.13.1-103.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.7-300.fc21.x86_64
type:           libreport

Created attachment 976463 [details]
patch to fix the file descriptor leak

Will be sending a couple of patches including this one that I had to fix up yesterday.

*** Bug 1183159 has been marked as a duplicate of this bug. ***

Wrt bug 1183159: I didn't recongize it as a duplicate because the subject line here shows a different problem.

But bug 1147705 is NEEDINFO, can someone restate what info you would like?

(In reply to John Heidemann from comment #30)
> Wrt bug 1183159: I didn't recongize it as a duplicate because the subject
> line here shows a different problem.

Thanks, it indeed looks different. But apparently many comments refer to the lock issue which is now fixed upstream as well as in some update

> But bug 1147705 is NEEDINFO, can someone restate what info you would like?

I guess the requested info is on the solution. Closing the needinfo now because we need to reexamine carefully. 

(In reply to Kevin Fenzi from comment #10)
> Yeah, please fix also rawhide/f20. ;)

So what's the current status of comment #3? Is it in all Fedora branches? Reassigning to selinux-policy for now.

If anyone is in doubt regarding dnssec-trigger, many issue have been fixed but an update for some of them is yet to be issued. You can try -17 (currently the latest) build from koji.

I no longer see this here. There's another denial, but can open a new bug for it: 

SELinux is preventing /usr/sbin/dnssec-triggerd from write access on the directory /etc.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow dnssec-triggerd to have write access on the etc directory
Then you need to change the label on /etc
Do
# semanage fcontext -a -t FILE_TYPE '/etc'
where FILE_TYPE is one of the following: dnssec_trigger_var_run_t, net_conf_t, var_run_t. 
Then execute: 
restorecon -v '/etc'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that dnssec-triggerd should be allowed write access on the etc 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 dnssec-triggerd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:dnssec_trigger_t:s0
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc [ dir ]
Source                        dnssec-triggerd
Source Path                   /usr/sbin/dnssec-triggerd
Port                          <Unknown>
Host                          voldemort.scrye.com
Source RPM Packages           dnssec-trigger-0.12-18.fc22.x86_64
Target RPM Packages           filesystem-3.2-32.fc22.x86_64
Policy RPM                    selinux-policy-3.13.1-106.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     voldemort.scrye.com
Platform                      Linux voldemort.scrye.com
                              3.19.0-0.rc6.git3.1.fc22.x86_64 #1 SMP Fri Jan 30
                              15:54:41 UTC 2015 x86_64 x86_64
Alert Count                   49
First Seen                    2015-01-20 07:12:06 MST
Last Seen                     2015-02-02 06:54:14 MST
Local ID                      371126d2-dc55-4451-9439-f1abe7abf639

Raw Audit Messages
type=AVC msg=audit(1422885254.181:9599): avc:  denied  { write } for  pid=8793 comm="dnssec-triggerd" name="etc" dev="dm-2" ino=1697281 scontext=system_u:system_r:dnssec_trigger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0


type=SYSCALL msg=audit(1422885254.181:9599): arch=x86_64 syscall=open success=no exit=EACCES a0=7fe650fcf480 a1=241 a2=1b6 a3=4000 items=0 ppid=1 pid=8793 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=dnssec-triggerd exe=/usr/sbin/dnssec-triggerd subj=system_u:system_r:dnssec_trigger_t:s0 key=(null)

Hash: dnssec-triggerd,dnssec_trigger_t,etc_t,dir,write

(In reply to Kevin Fenzi from comment #32)
> If you want to allow dnssec-triggerd to have write access on the etc
> directory

This is the result of fixing bug #1165746 where dnssec-trigger originally rewrote the /etc/resolv.conf contents whereas other tools created a new file in /etc/ and moved it over to /etc/resolv.conf. Now dnssec-triggerd works like other tools.

Do you want to open a new bug?

I can if I see it again. As far as I am concerned this bug is fixed.

Can you send an updated build to F20 Updates testing? Or are you waiting for SELinux to be fixed?

I believe this is only for F21, right?

(In reply to Miroslav Grepl from comment #37)
> I believe this is only for F21, right?

And F20.

(In reply to Moez Roy from comment #38)
> (In reply to Miroslav Grepl from comment #37)
> > I believe this is only for F21, right?
> 
> And F20.

The package is always built for all >=F20 branches. So I would prefer if we could have the policy for all those versions as well, otherwise we'd need to abandon the practice which comes from the fact that the whole dnssec-trigger thing was experimental and we supported experimenting with it since F20.

I recommend that the policy is ready on >=F20 and then the bug is closed.

agree I add fixes also for F20 branch

Any update on this? Thanks!

commit 06005bc0ac9370f93ba99e44d478e9930f3896c1
Author: Lukas Vrabec <lvrabec>
Date:   Thu Apr 9 21:06:09 2015 +0200

    Allow dnssec_trigger_t to stream connect to networkmanager.

commit 2c3a0d6d02474851e2ffd711ae8fd5176003624e
Author: Lukas Vrabec <lvrabec>
Date:   Thu Apr 9 19:35:47 2015 +0200

    Allow dnssec_trigger_t to create resolv files labeled as net_conf_t

commit cfb2997e16f7106c916c903d4aac2aa9102ba7bf
Author: Lukas Vrabec <lvrabec>
Date:   Thu Apr 9 17:57:43 2015 +0200

    Label new dnssec-trigger files.

selinux-policy-3.13.1-105.13.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-105.13.fc21

Package selinux-policy-3.13.1-105.13.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-105.13.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-6316/selinux-policy-3.13.1-105.13.fc21
then log in and leave karma (feedback).

selinux-policy-3.13.1-105.13.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

The AVC is still triggers on Fedora 20. Do you plan to submit an update for it?

The AVC is still triggered on Fedora 20. Can the update be submitted before the end-of-life of F20?

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.