Bug 509502
| Summary: | setroubleshoot/sealert references smtp_port_t as device_t | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Allen Kistler <ackistler> |
| Component: | setroubleshoot-plugins | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | dwalsh, jdennis, mgrepl, vchepkov |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | setroubleshoot-plugins-2.0.18-5.fc11 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-08-18 21:30:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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