Description of problem: SELinux is preventing sh from 'execute' accesses on the file /usr/sbin/unbound-control. ***** Plugin catchall (100. confidence) suggests ************************** If sie denken, dass es sh standardmässig erlaubt sein sollte, execute Zugriff auf unbound-control file zu erhalten. Then sie sollten dies als Fehler melden. Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen. Do zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen: # grep sh /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:named_exec_t:s0 Target Objects /usr/sbin/unbound-control [ file ] Source sh Source Path sh Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages unbound-1.4.22-5.fc21.x86_64 Policy RPM selinux-policy-3.13.1-82.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.16.3-302.fc21.x86_64 #1 SMP Fri Sep 26 14:27:20 UTC 2014 x86_64 x86_64 Alert Count 2 First Seen 2014-09-29 20:49:36 CEST Last Seen 2014-09-29 20:49:37 CEST Local ID 10f40912-a6cd-42c1-8d14-c661d1c5e257 Raw Audit Messages type=AVC msg=audit(1412016577.526:394): avc: denied { execute } for pid=1642 comm="sh" name="unbound-control" dev="dm-0" ino=260590 scontext=system_u:system_r:dnssec_trigger_t:s0 tcontext=system_u:object_r:named_exec_t:s0 tclass=file permissive=0 Hash: sh,dnssec_trigger_t,named_exec_t,file,execute Version-Release number of selected component: selinux-policy-3.13.1-82.fc21.noarch Additional info: reporter: libreport-2.2.3 hashmarkername: setroubleshoot kernel: 3.16.3-302.fc21.x86_64 type: libreport
*** 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.