Bug 198039 - selinux policy prevents proper shutdown
selinux policy prevents proper shutdown
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-08 09:14 EDT by Jurgen Kramer
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-11 03:54:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jurgen Kramer 2006-07-08 09:14:15 EDT
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
Comment 1 James Morris 2006-07-08 10:54:51 EDT
Is this using the latest policy, and what if any SELinux related iptables
labeling rules are in effect?
Comment 2 Jurgen Kramer 2006-07-08 12:06:39 EDT
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.
Comment 3 Stephen Smalley 2006-07-10 16:41:36 EDT
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.  
Comment 4 Eric Paris 2006-07-10 17:16:13 EDT
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...
Comment 5 Daniel Walsh 2006-07-11 14:20:14 EDT
We could set this up as a boolean that is turned on and off by the initscripts for 
iptables?
Comment 6 Jurgen Kramer 2006-08-11 03:54:09 EDT
With the current selinux rules the system shuts down normally.

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