Description of problem: I start stunnel as a daemon from an init script. I'm confining it using SELinux. However, at one point in my development I got an AVC denial that setroubleshoot/sealert suggested I had mislabeled the target port as device_t, but it wasn't even close to device_t. Version-Release number of selected component (if applicable): setroubleshoot-2.1.14-1.fc11 How reproducible: Always Steps to Reproduce: 1. Configure stunnel to bind to just about any port (e.g., tcp/465) 2. Run setroubleshoot-server 3. Run stunnel as stunnel_t Actual results: --- begin --- SELinux is preventing stunnel (stunnel_t) "name_bind" access to device <Unknown>. Detailed Description: SELinux has denied the stunnel (stunnel_t) "name_bind" access to device <Unknown>. <Unknown> is mislabeled, this device has the default label of the /dev directory, which should not happen. All Character and/or Block Devices should have a label. You can attempt to change the label of the file using restorecon '<Unknown>'. If this device remains labeled device_t, then this is a bug in SELinux policy. --- end --- Expected results: The target is tcp_socket smtp_port_t, not "device <Unknown>" with label device_t. Additional info: For reference, below is the denial record for which the troubleshooter tried to help. Note that this bug report is only about the erroneous help text, not the denial itself. node=ack602 type=AVC msg=audit(1245975626.960:170): avc: denied { name_bind } for pid=4872 comm="stunnel" src=465 scontext=unconfined_u:system_r:stunnel_t:s0 tcontext=system_u:object_r:smtp_port_t:s0 tclass=tcp_socket
Yes that plugin needs to be removed. Fixed in setroubleshoot-plugins-2.1.7-1
*** Bug 509638 has been marked as a duplicate of this bug. ***
*** Bug 509498 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Yes that plugin needs to be removed. > > Fixed in setroubleshoot-plugins-2.1.7-1 Will there be a version for F11? Even in Koji, the latest for F11 is setroubleshoot-plugins-2.0.18-2, which doesn't have the fix. setroubleshoot-plugins-2.1.x appears to be for rawhide/F12 only, with setroubleshoot-plugins-2.0.x for F10 & F11 only. Perhaps confusion arose because I originally files against setroubleshoot, which is numbered differently from setroubleshoot-plugins...?
Sending back to ASSIGNED (through CLOSED) for F11.
I just released the updated package from Fedora-testing for F11.
So updates-testing has setroubleshoot-plugins-2.0.18-2.fc11.noarch, which is the latest Koji has, too. Feeding the log through sealert yields (*** mine): === begin === SELinux is preventing stunnel (stunnel_t) "name_bind" access to device <Unknown>. Detailed Description: SELinux has denied the stunnel (stunnel_t) "name_bind" access to device <Unknown>. ***---vvv <Unknown> is mislabeled, this device has the default label of the /dev directory, which should not happen. All Character and/or Block Devices should have a label. You can attempt to change the label of the file using restorecon '<Unknown>'. If this device remains labeled device_t, then this is a bug in SELinux policy. Allowing Access: If you want the SSL Tunnel to run as a daemon you need to turn on the vvv--***---vvv---***---vvv---***---vvv---***---vvv---***--vvv stunnel_is_daemon boolean: "setsebool -P stunnel_is_daemon=1". You also need to tell SELinux which port SSL Tunnel will be running on. semanage port -a -t stunnel_port_t -p tcp 465 Fix Command: setsebool -P stunnel_is_daemon=1 <<<---*** Additional Information: Source Context unconfined_u:system_r:stunnel_t:s0 Target Context system_u:object_r:smtp_port_t:s0 Target Objects None [ tcp_socket ] Source stunnel Source Path <Unknown> Port 465 Host ack602 Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name stunnel_is_daemon <<<---*** Host Name ack602 Platform Linux ack602 2.6.29.6-213.fc11.i586 #1 SMP Tue Jul 7 20:45:17 EDT 2009 i686 i686 Alert Count 1 First Seen Thu Jun 25 19:20:26 2009 Last Seen Thu Jun 25 19:20:26 2009 Local ID 0e66c374-f84d-48d9-b1f7-14a57027dc22 Line Numbers 1 === end === So if the solution is to remove the stunnel_is_daemon plugin, it's still not removed. /usr/share/setroubleshoot/plugins/stunnel_is_daemon.py
Removed from setroubleshoot-plugins-2.0.18-3.fc11
(In reply to comment #8) > Removed from setroubleshoot-plugins-2.0.18-3.fc11 I snagged the package out of Koji. The output is still as in Comment 7 and ... # rpm -qf /usr/share/setroubleshoot/plugins/stunnel_is_daemon.py setroubleshoot-plugins-2.0.18-3.fc11.noarch ... back to ASSIGNED ...
Yup, still there, One more try. Removed from setroubleshoot-plugins-2.0.18-4.fc11
(In reply to comment #10) > Yup, still there, > > One more try. > > Removed from setroubleshoot-plugins-2.0.18-4.fc11 Still there. # rpm -qf /usr/share/setroubleshoot/plugins/stunnel_is_daemon.py setroubleshoot-plugins-2.0.18-4.fc11.noarch
Ok here is my excuse. I am supposed to be on vacation, and I am just working a couple of hours every morning to try to keep up. So I am obviously have a combination of booze, icecream and too much sun. Lets try again in setroubleshoot-plugins-2.0.18-5.fc11
(In reply to comment #12) > Ok here is my excuse. I am supposed to be on vacation ... > > Lets try again in setroubleshoot-plugins-2.0.18-5.fc11 The plugin's really gone this time. So you can stop checking your email now and sleep late, instead.
It's in updates. Closing.