Description of problem: The Cagibi daemon (UPnP SSDP device discovery protocol client used by KDE) is autospawned by system DBus and running as initrc_t under root. It needs to be able to use the default SSDP UDP port (port 1900) to work properly. The port even has its own type of ssdp_port_t, but allowing initrc_t name_bind to ssdp_port_t is not a particularly clean solution. This problem is visible only after confining initrc_t by disabling unconfined.pp. Additional info: libreport version: 2.0.18 kernel: 3.6.5-1.fc17.x86_64 description: :SELinux is preventing /usr/bin/cagibid from 'name_bind' accesses on the udp_socket . : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that cagibid should be allowed name_bind access on the udp_socket 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 cagibid /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:initrc_t:s0-s0:c0.c1023 :Target Context system_u:object_r:ssdp_port_t:s0 :Target Objects [ udp_socket ] :Source cagibid :Source Path /usr/bin/cagibid :Port 1900 :Host (removed) :Source RPM Packages cagibi-0.2.0-4.fc17.x86_64 :Target RPM Packages :Policy RPM selinux-policy-3.10.0-156.fc17.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.6.5-1.fc17.x86_64 #1 SMP Wed Oct : 31 19:37:18 UTC 2012 x86_64 x86_64 :Alert Count 12 :First Seen 2012-10-21 21:32:26 CEST :Last Seen 2012-11-04 14:02:22 CET :Local ID 1af8c412-3930-4177-b05c-21dad36fa932 : :Raw Audit Messages :type=AVC msg=audit(1352034142.949:694): avc: denied { name_bind } for pid=1791 comm="cagibid" src=1900 scontext=system_u:system_r:initrc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssdp_port_t:s0 tclass=udp_socket : : :type=SYSCALL msg=audit(1352034142.949:694): arch=x86_64 syscall=bind success=no exit=EACCES a0=7 a1=7fffcd1b9ae0 a2=10 a3=7fffcd1b9840 items=0 ppid=1 pid=1791 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=cagibid exe=/usr/bin/cagibid subj=system_u:system_r:initrc_t:s0-s0:c0.c1023 key=(null) : :Hash: cagibid,initrc_t,ssdp_port_t,udp_socket,name_bind : :audit2allow : :#============= initrc_t ============== :allow initrc_t ssdp_port_t:udp_socket name_bind; : :audit2allow -R : :#============= initrc_t ============== :allow initrc_t ssdp_port_t:udp_socket name_bind; :
Created attachment 638064 [details] File: type
Created attachment 638065 [details] File: hashmarkername
Hi, This daemon needs a policy Could you help us by doing the following: 1. create a work directory called cagibi with a cagibi.te and cagibi.fc file in it mkdir ~/cagibi; cd ~/cagibi; touch cagibi.{te,fc} 2. Add the following to the cagibi.te file: policy_module(cagibi, 1.0.0) type cagibid_t; type cagibid_exec_t; dbus_system_domain(cagibid_t, cagibid_exec_t) type cagibid_conf_t; files_config_file(cagibid_conf_t) permissive cagibid_t; corenet_all_recvfrom_unlabeled(cagibid_t) corenet_all_recvfrom_netlabel(cagibid_t) corenet_tcp_sendrecv_generic_if(cagibid_t) corenet_tcp_sendrecv_generic_node(cagibid_t) corenet_tcp_bind_generic_node(cagibid_t) corenet_sendrecv_ssdp_server_packets(cagibid_t) corenet_tcp_bind_ssdp_port(cagibid_t) corenet_tcp_sendrecv_ssdp_port(cagibid_t) 2. Add the following to the cagibi.fc file: /etc/cagibid\.conf -- gen_context(system_u:object_r:cagibid_conf_t,s0) /usr/bin/cagibid -- gen_context(system_u:object_r:cagibid_exec_t,s0) 3. Build a binary policy package ( may or may not require that you install seliux-policy-devel ): make -f /usr/share/selinux/devel/Makefile cagibi.pp 4. Install the compiled policy package: sudo semodule -i cagibi.pp 5. Restore the context of /etc/cagibid.conf and /usr/bin/cagibid restorecon -v /etc/cagibid.conf restorecon -v /usr/bin/cagibid 6. Test cagibi and provide feedback by enclosing related avc denials: "do some tests" ausearch -m avc -ts recent "enclose ausearch output" Better even is to test it a few times by just appending the ausearch output piped into audit2allow -r to the ~/cagibi.te file rebuilding and testing again until there are no more selinux denials shown: ausearch -m avc -ts recent | audit2allow -r >> ~/cagibi/cagibi.te make -f /usr/share/selinux/devel/Makefile cagibi.pp sudo semodule -i cagibi.pp "do some tests" ausearch -m avc -ts recent | audit2allow -r >> ~/cagibi/cagibi.te make -f /usr/share/selinux/devel/Makefile cagibi.pp sudo semodule -i cagibi.pp "do some more tests" ausearch -m avc -ts recent | audit2allow -r >> ~/cagibi/cagibi.te make -f /usr/share/selinux/devel/Makefile cagibi.pp sudo semodule -i cagibi.pp "etc etc, until no more avc denials" Then enclose both all AVC denials as well as your cagibi.te and cagibi.fc file Note that is important that you also enclose the avc denials so that we can verify that the optimal security decisions were made Thanks in advance!
Oh, i forgot: Additionally check for DBUS related AVC denials These can be found if you use: ausearch -m user_avc -ts recent
Whoops, and this: corenet_all_recvfrom_unlabeled(cagibid_t) corenet_all_recvfrom_netlabel(cagibid_t) corenet_tcp_sendrecv_generic_if(cagibid_t) corenet_tcp_sendrecv_generic_node(cagibid_t) corenet_tcp_bind_generic_node(cagibid_t) corenet_sendrecv_ssdp_server_packets(cagibid_t) corenet_tcp_bind_ssdp_port(cagibid_t) corenet_tcp_sendrecv_ssdp_port(cagibid_t) should be this: corenet_all_recvfrom_unlabeled(cagibid_t) corenet_all_recvfrom_netlabel(cagibid_t) corenet_udp_sendrecv_generic_if(cagibid_t) corenet_udp_sendrecv_generic_node(cagibid_t) corenet_udp_bind_generic_node(cagibid_t) corenet_sendrecv_ssdp_server_packets(cagibid_t) corenet_udp_bind_ssdp_port(cagibid_t) corenet_udp_sendrecv_ssdp_port(cagibid_t)
Actually its not dbus that ran this but it is systemd.. so please add under "dbus_system_domain(cagibid_t, cagibid_exec_t)" in cagibi.te the following: init_daemon_domain(cagibid_t, cagibid_exec_t)
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Hi Dominic, This is old bug but do you have this policy?
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days