Bug 509502 - setroubleshoot/sealert references smtp_port_t as device_t
setroubleshoot/sealert references smtp_port_t as device_t
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: setroubleshoot-plugins (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
: 509498 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-03 02:48 EDT by Allen Kistler
Modified: 2009-08-18 17:30 EDT (History)
4 users (show)

See Also:
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 17:30:24 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 Allen Kistler 2009-07-03 02:48:46 EDT
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
Comment 1 Daniel Walsh 2009-07-06 16:45:20 EDT
Yes that plugin needs to be removed.

Fixed in setroubleshoot-plugins-2.1.7-1
Comment 2 Daniel Walsh 2009-07-06 16:46:09 EDT
*** Bug 509638 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Walsh 2009-07-06 17:04:03 EDT
*** Bug 509498 has been marked as a duplicate of this bug. ***
Comment 4 Allen Kistler 2009-07-23 20:25:33 EDT
(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...?
Comment 5 Allen Kistler 2009-07-30 15:16:02 EDT
Sending back to ASSIGNED (through CLOSED) for F11.
Comment 6 Daniel Walsh 2009-07-30 17:12:02 EDT
I just released the updated package from Fedora-testing for F11.
Comment 7 Allen Kistler 2009-07-30 19:49:42 EDT
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
Comment 8 Daniel Walsh 2009-07-31 06:35:52 EDT
Removed from setroubleshoot-plugins-2.0.18-3.fc11
Comment 9 Allen Kistler 2009-07-31 23:00:14 EDT
(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 ...
Comment 10 Daniel Walsh 2009-08-04 06:28:19 EDT
Yup, still there,

One more try.

Removed from setroubleshoot-plugins-2.0.18-4.fc11
Comment 11 Allen Kistler 2009-08-04 11:01:48 EDT
(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
Comment 12 Daniel Walsh 2009-08-05 08:13:14 EDT
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
Comment 13 Allen Kistler 2009-08-05 10:39:35 EDT
(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.
Comment 14 Allen Kistler 2009-08-18 17:30:24 EDT
It's in updates.  Closing.

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