Description of problem: the current selinux policy (targeted) prevents various deamons from functioning properly (even on lo I/F). Version-Release number of selected component (if applicable): (running current FC6 devel) policycoreutils-1.30.17-1 libselinux-1.30.19-1 etc. How reproducible: allways Steps to Reproduce: 1. Shutdown system 2. see various denied messages (+/- 3 minutes) 3. system shuts down Actual results: It takes about 3 minutes to shutdown because of various daemons are not able to communicate. Expected results: Proper shutdown Additional info: Jul 8 14:41:58 macbook kernel: audit(1152362518.377:81): avc: denied { send } for pid=6479 comm="rndc" saddr=127.0.0.1 src=59947 daddr=127.0.0.1 dest=953 netif=lo scontext=system_u:system_r:ndc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Jul 8 14:42:01 macbook kernel: audit(1152362521.377:82): avc: denied { send } for saddr=127.0.0.1 src=59947 daddr=127.0.0.1 dest=953 netif=lo scontext=system_u:system_r:ndc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Jul 8 14:42:03 macbook hcid[5999]: Can't open system message bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Jul 8 14:42:07 macbook kernel: audit(1152362527.377:83): avc: denied { send } for saddr=127.0.0.1 src=59947 daddr=127.0.0.1 dest=953 netif=lo scontext=system_u:system_r:ndc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Jul 8 14:42:08 macbook hcid[5999]: Can't open system message bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Jul 8 14:42:18 macbook last message repeated 2 times Jul 8 14:42:19 macbook kernel: audit(1152362539.378:84): avc: denied { send } for saddr=127.0.0.1 src=59947 daddr=127.0.0.1 dest=953 netif=lo scontext=system_u:system_r:ndc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Jul 8 14:42:23 macbook hcid[5999]: Can't open system message bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Jul 8 14:42:43 macbook last message repeated 4 times Jul 8 14:42:43 macbook kernel: audit(1152362563.379:85): avc: denied { send } for saddr=127.0.0.1 src=59947 daddr=127.0.0.1 dest=953 netif=lo scontext=system_u:system_r:ndc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Jul 8 14:42:48 macbook hcid[5999]: Can't open system message bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Jul 8 14:43:23 macbook last message repeated 7 times Jul 8 14:43:28 macbook hcid[5999]: Can't open system message bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Jul 8 14:43:31 macbook kernel: audit(1152362611.378:86): avc: denied { send } for saddr=127.0.0.1 src=59947 daddr=127.0.0.1 dest=953 netif=lo scontext=system_u:system_r:ndc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Jul 8 14:43:33 macbook hcid[5999]: Can't open system message bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Jul 8 14:44:08 macbook last message repeated 7 times Jul 8 14:45:03 macbook last message repeated 11 times
Is this using the latest policy, and what if any SELinux related iptables labeling rules are in effect?
I am using the latest FC6 policy: selinux-policy-targeted-2.3.1-1. I did not make any alterations to the iptables rule base.
The problem is that the packet class was added to the refpolicy along with a set of packet types and rules, but no iptables rules were put into place to assign those types to the packets via secmark, and refpolicy did not allow packets that were left in unlabeled_t to be sent/received (as the goal was to avoid having to do so, since unlabeled_t can also be the result of a SID invalidation via policy reload). I asked Chris PeBenito to add unlabeled_t:packet permissions pervasively as an interim measure, and that should be present in the latest refpolicy. But we do need to work out the iptables rules for properly labeling the packets for real use of secmark, and coordinate them with policy in some manner.
A very pervasive troubleshooting tactic and common install situation in commercial setups have iptables basically 'off.' Certainly, even in the long run, there has to be some method in which we can have SELinux on and iptables 'off.' I think I'm trying to understand how we can say 'unlabeled_t:packet is an interim measure'. I'm not sure where the plan to add the iptables labeleing rules are, but if they come from the standard RHEL /etc/sysconfig/iptables file and rely on /etc/init.d/iptables we can pretty much rest assured that unlabel_t will never be able to go away...
We could set this up as a boolean that is turned on and off by the initscripts for iptables?
With the current selinux rules the system shuts down normally.