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 remedy using a Boolean, stunnel_is_daemon. No such Boolean exists in /selinux/booleans. I also searched the selinux-policy source and only found a reference to it in booleans-mls.conf, but nowhere else. I suspect that the Boolean is obsolete and that the help text from the troubleshooter just needs to be updated to eliminate the reference. 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>. --- snip --- Allowing Access: If you want the SSL Tunnel to run as a daemon you need to turn on the 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 --- end --- Expected results: "Allowing Access" shouldn't mention stunnel_is_daemon, since it appears to be obsolete. "device <Unknown>" seems a little shady, too, but that a different bug. 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
*** This bug has been marked as a duplicate of bug 509502 ***