Bug 653579 - SELinux is preventing /usr/sbin/sshd from binding to port 3388.
Summary: SELinux is preventing /usr/sbin/sshd from binding to port 3388.
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 17
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:922d4047b75...
Keywords: SELinux
: 656813 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-11-15 18:00 UTC by cando
Modified: 2013-08-05 00:07 UTC (History)
11 users (show)

Clone Of:
Last Closed: 2012-08-06 07:20:24 UTC

Attachments (Terms of Use)

Description cando 2010-11-15 18:00:05 UTC
This seems to be the same as the bug reported for Fedora 9: https://bugzilla.redhat.com/show_bug.cgi?id=464312.
I'm woundering if it didn't get applied to more recent active releases and the one in devel at the time of the bug being resolved or it just crept back in.



SELinux is preventing /usr/sbin/sshd from binding to port 3388.

Detailed Description:

SELinux has denied the sshd from binding to a network port 3388 which does not
have an SELinux type associated with it. If sshd should be allowed to listen on
3388, use the semanage command to assign 3388 to a port type that sshd_t can
bind to (xserver_port_t, ssh_port_t).
If sshd is not supposed to bind to 3388, this could signal an intrusion attempt.

Allowing Access:

If you want to allow sshd to bind to port 3388, you can execute
# semanage port -a -t PORT_TYPE -p tcp 3388
where PORT_TYPE is one of the following: xserver_port_t, ssh_port_t.
If this system is running as an NIS Client, turning on the allow_ypbind boolean
may fix the problem. setsebool -P allow_ypbind=1.

Additional Information:

Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:port_t:s0
Target Objects                None [ tcp_socket ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          3388
Host                          (removed)
Source RPM Packages           openssh-server-5.5p1-22.fc14.2
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-10.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   bind_ports
Host Name                     (removed)
Platform                      Linux viper.wideideas.net #1
                              SMP Fri Oct 22 15:34:36 UTC 2010 i686 i686
Alert Count                   2
First Seen                    Sun 14 Nov 2010 11:51:28 AM PST
Last Seen                     Sun 14 Nov 2010 11:51:28 AM PST
Local ID                      1edb3c31-334b-4a8f-b6a0-df1aa175288d
Line Numbers                  

Raw Audit Messages            

node=viper.wideideas.net type=AVC msg=audit(1289764288.142:63831): avc:  denied  { name_bind } for  pid=27948 comm="sshd" src=3388 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

node=viper.wideideas.net type=SYSCALL msg=audit(1289764288.142:63831): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bf8686e0 a2=a737a8 a3=249bee8 items=0 ppid=1636 pid=27948 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3038 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  bind_ports,sshd,sshd_t,port_t,tcp_socket,name_bind
audit2allow suggests:

#============= sshd_t ==============
#!!!! This avc can be allowed using one of the these booleans:
#     sshd_forward_ports, allow_ypbind

allow sshd_t port_t:tcp_socket name_bind;

Comment 1 cando 2010-11-15 18:35:20 UTC
I was connecting from winxp at home to fedora 14 desktop at work using putty. I tried to setup port forwarding so I could use windows RDP to another win computer in the same net as the fedora 14 box.  I did first try local (home winxp) listening on port 3388 and the remote (fedora box) would deliver to port 3889 (RDP port) on remote windows box. I tried several things but none worked. I'm guessing this selinix block action was a result of trying to set it up to remotely (the fedora box) listen on the 3388.

When I was denied forwarding as I first tried as described above, I was not given the option to report the selinux blocked activity from the SELinux Security Alerts dialog. So since it is still on the topic of selinux and it not allowing port forwarding, I've included it in this bug report. I'm new to reporting bugs so I'm sorry if this is wrong/taboo.
Here is the message from the warning (this one was actually for VNC forward but same diff):


SELinux is preventing /usr/sbin/sshd "name_connect" access on <Unknown>.

Detailed Description:

SELinux denied access requested by sshd. The current boolean settings do not
allow this access. If you have not setup sshd to require this access this may
signal an intrusion attempt. If you do intend this access you need to change the
booleans on this system to allow the access.

Allowing Access:

Confined processes can be configured to run requiring different access, SELinux
provides booleans to allow you to turn on/off access as needed. The boolean
sshd_forward_ports is set incorrectly.
Boolean Description:
allow sshd to forward port connections

Fix Command:

# setsebool -P sshd_forward_ports 1

Additional Information:

Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:vnc_port_t:s0
Target Objects                None [ tcp_socket ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          5900
Host                          (removed)
Source RPM Packages           openssh-server-5.5p1-22.fc14.2
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-10.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall_boolean
Host Name                     (removed)
Platform                      Linux (removed) #1
                              SMP Fri Oct 22 15:34:36 UTC 2010 i686 i686
Alert Count                   2
First Seen                    Mon 15 Nov 2010 10:22:14 AM PST
Last Seen                     Mon 15 Nov 2010 10:22:30 AM PST
Local ID                      363ca887-7224-4b49-91ef-4cad2b8317d4
Line Numbers                  

Raw Audit Messages            

node=viper.wideideas.net type=AVC msg=audit(1289845350.62:72919): avc:  denied  { name_connect } for  pid=331 comm="sshd" dest=5900 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket

node=viper.wideideas.net type=SYSCALL msg=audit(1289845350.62:72919): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb92310 a2=92d7a8 a3=4 items=0 ppid=1636 pid=331 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4431 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Comment 2 Miroslav Grepl 2010-11-16 08:33:12 UTC
Did you read sealert?


Allowing Access:

Confined processes can be configured to run requiring different access, SELinux
provides booleans to allow you to turn on/off access as needed. The boolean
sshd_forward_ports is set incorrectly.
Boolean Description:
allow sshd to forward port connections

Fix Command:

# setsebool -P sshd_forward_ports 1


So just execute

# setsebool -P sshd_forward_ports 1

Comment 3 cando 2010-11-16 18:33:38 UTC
I did read the sealert and used the command it and you suggested. It worked fine to get it working.
However port forwarding is enabled in sshd config and not in selinux. This is my point and the point of the bug report for Fedora 9 referred to earlier. Since you didn't address that issue I assume I wasn't clear before as to what I felt the "bug" was.
Forgive the below if it comes across as a rant. I do very much appreciate the work and efforts being made to make things more secure and better over all.

The thing that is driving me nuts about selinux is that it breaks things quietly. They don't work when they use to and your left scratching your head till you finally think, I wounder if this is a selinux problem then find it in the log and try to fix / workaround around the problem.

It was nice when I got back to my office desktop and saw the selinux icon notifying me selinux had blocked something and examining it I found the reason for things not working and changing the settings as it suggested. However that didn't help me when I was trying to connect from home and couldn't remotely control my computer when I needed to.
I understand it is hard to work backwards from having tools that were built before selinux be selinux aware and present the user with info about the selinux restriction.

Anyway... It needs to be more consistent between software settings and selinux and documented.
sshd port forwarding should be disabled by default to match selinux or the other way around but be consistant. The config file should also document the selinux setting change needed for port forwarding to work. sshd and ssh documentation (man page) should also reflect this. This would also help people be more accepting of selinux instead of feeling like they are fighting it blind.
For me there have been cases where we just had to turn off and leave off selinux on our servers in order to run our business due to time/money constraints to find the "right" solution.

Well. That is my perspective and I leave it to those more experienced to choose the best action for this "bug".

Thanks again for your time and efforts.

Comment 4 Daniel Walsh 2010-11-16 18:42:41 UTC
I agree, port forwarding should be off by default.  Most people never use it.  The goal with SELinux is to pick reasonable defaults, I think saying sshd should not be allowed to forward ports is a reasonable default.

I also have no problems with putting a little documentation in the ssh config file stating that you need to configure SELinux to make the change work.

Comment 5 Tomas Mraz 2010-11-16 20:20:17 UTC
I do not agree with this reasoning. The port forwarding is enabled by default by upstream in sshd and we want to diverge from it as little as possible. I do not see a big problem with SELinux disabling it by default if sealert suggests the correct 'setsebool -P sshd_forward_ports 1' remedy.

Comment 6 Daniel Walsh 2010-11-17 16:34:52 UTC
Can we add a comment line in the config mentioning this then?

Comment 7 cando 2010-11-17 17:58:58 UTC
Sure would be nice to see it in the man pages for sshd and ssh (though probably needs to be addressed with openssh developers). Especially ssh since that is where you first look to figure out how to do port forwarding. Something like "On server you are connecting through, it must have AllowTcpForwarding set to yes and SELinux boolean option must be set to allow it (ie: setsebool -P sshd_forward_ports 1)." Not positive AllowTcpForwarding is the pertinent option, but you get the idea.

It is great that sealert gives that proper remedy (which I used successfully) but the problem is with it's visability. Unless you are used to dealing with selinux without the GUI app that pops up to let you know there was a violation that was blocked, you (like I did) wouldn't automatically think to go looking for if/why selinux blocked what you were trying to do.

Would it be possible for selinux to send a message, like the method used when the system is shutting down, to the terminal where the violation occured? It could say something like "SELinux blocked the operation. See /var/log/audit/audit.log for more details." That would be save so much head scratching time, reduce selinux ill will, and people would embrace it more readily rather than get frustrated and disable it completely.

Comment 8 Tomas Mraz 2010-11-18 08:02:57 UTC
(In reply to comment #6)
> Can we add a comment line in the config mentioning this then?

Yes, I think adding a comment in the /etc/ssh/sshd_config would be fine. Jan, can you please do that?

Comment 9 Jan F. Chadima 2010-11-18 15:35:39 UTC
Probably the same problem may cause ssh with the reverse port mapping. IMHO the best way how to document this behavior is to write generic howto about port forwarding in ssh and selinux. This should not be part of ss nor sshd documentation because it is common.

Comment 10 Miroslav Grepl 2010-11-24 12:35:01 UTC
*** Bug 656813 has been marked as a duplicate of this bug. ***

Comment 11 John Hein 2010-11-24 15:39:13 UTC
Maybe "most" people don't use port forwarding, but I'm sure a healthy percentage of people do.  I don't agree it should be disabled by default.  I can't vnc directly to a default fedora installation because of firewall rules (and vnc is just one example I picked from the hat).  Considering the default settings for the firewall, we should at least allow ssh tunneling to work.

I'll have to agree with the gist of comment 3.  The first thing I do after installing fedora is disable selinux (or set to permissive) because of these problems that always show up.  When I don't, I pay.

That said, I understand that configuring default selinux policy properly is a difficult task considering all the interactions, and I'm just replying here to help provide some feedback.

Comment 12 John Hein 2010-11-24 17:07:47 UTC
By the way, while tracking down this problem, I restarted sshd manually: 'sudo /usr/sbin/sshd'.  When I did that (and before did any changes to selinux policy, so the sshd_forward_ports selinux setting was still off), port forwarding _was_ working.  But when I used 'sudo /etc/init.d/sshd start', selinux would reject the port forwarding.  No changes to sshd_config.

Anyone know why starting sshd with 'sudo /usr/sbin/sshd' (with sshd_forward_ports off and selinux set to enforcing) would allow port forwarding?  But using /etc/init.d/sshd behaves as expected?  I traced through /etc/init.d/sshd and it starts sshd without any other options.  /etc/sysconfig/sshd does not exist.

This is directly related to this bug since it was befuddling why when I manually started sshd port forwarding worked, but starting sshd from boot did not.

Comment 13 Daniel Walsh 2010-11-24 18:18:48 UTC


Comment 14 Tim Taiwanese Liim 2010-11-25 04:58:57 UTC
Can someone please point out what evil ssh port forwarding brings?
When people say "it works in Ubuntu; Fedora sucks because the basic
thing (like ssh port forwarding or vnc) does not work," it's really
hard to defend for Fedora.

Comment 15 Tomas Mraz 2010-11-25 07:44:08 UTC
Thinking of it more I agree that the ssh port forwarding SELinux boolean should be on by default in the targeted policy.

Comment 16 John Hein 2010-11-27 18:20:09 UTC
Re: comment 13.  Thanks Dan for the explanation regarding the difference between running sshd via init.d vs. directly.  I guess I see the issue: 

> secon --file /etc/init.d/sshd
user: system_u
role: object_r
type: sshd_initrc_exec_t
sensitivity: s0
clearance: s0
mls-range: s0
> secon --file /usr/sbin/sshd
user: system_u
role: object_r
type: sshd_exec_t
sensitivity: s0
clearance: s0
mls-range: s0

Some day perhaps it will become more intuitive how all the selinux interactions cooperate.  But now we wander too far off topic.

Comment 17 Daniel Walsh 2010-11-29 16:17:01 UTC
Tomas, I disagree.   MOST users will never know how to turn on/off port forwarding,  and since we turn sshd on by default this allows an attack vector for very little benefit,  I would argue that it should be off by default on both sshd config and selinux.  People who know what it is should now how to turn it on.

Comment 18 John Hein 2010-11-29 17:06:37 UTC
I have never heard of an attack or exploit due to port forwarding being turned on.  I don't agree with the assessment that it's dangerous.  Upstream would not leave it on by default were that not the case.

Moreover the benefits of port forwarding are wide and varied.  For instance, before ssh port forwarding, the best option for displaying remote X apps was to listen for X connections on INADDR_ANY - is that better?  Without ssh port forwarding, opening up vnc ports will become more commonplace - with vnc's weak authentication models, that will do far more to degrade security than disabling ssh port forwarding.

Comment 19 Daniel Walsh 2010-11-29 20:21:39 UTC
I believe ssh -X -Y remhost works without SELinux allowing port forwarding.

Comment 20 Daniel Walsh 2010-11-29 21:08:29 UTC
When you turn this boolean on, sshd can connect to any port and bind on any port, allowing it to impersonate any app and then forward the connections to any port.

The default is

sesearch -A -s sshd_t  -C | grep -v "\[" | grep name_connect
   allow sshd_t ldap_port_t : tcp_socket { recv_msg send_msg name_connect } ; 
   allow sshd_t dns_port_t : tcp_socket { recv_msg send_msg name_connect } ; 

sesearch -A -s sshd_t  -C | grep -v "\[" | grep name_bind
   allow sshd_t xserver_port_t : tcp_socket name_bind ; 
   allow sshd_t ssh_port_t : tcp_socket name_bind ; 

So turning this on allows a bug in sshd to become a relay without potentially even getting a login password on the system.

Comment 21 John Hein 2010-11-29 21:34:28 UTC
re: ssh -Y; that's good to know.  Although it's probably a special case that is surprising to SELinux users who might set sshd_forward_ports set to 1 on purpose.  Is that exception well documented in the selinux docs?  I couldn't verify that since I could not find the docs for the selinux booleans in the man pages or a google search or in the selinux-doc package.

But it's still only one case of port forwarding (with some extra sugar that sets DISPLAY and does the xauth(1) dance).

From a security standpoint, I'd certainly prefer ssh port forwarding over punching holes in the firewall to expose less secure services.  The latter is what I elected to do before I eventually found this bugzilla entry explaining the problem.

Not to mention the POLA issue.  I realize that my preference is not always a good global default (although in this case I think it is).  But I think at the very least such a policy change requires some advance notice and/or a release notes entry at the level of the fedora release (I just checked in case I missed it but didn't find anything).

Comment 22 Tomas Mraz 2010-11-29 22:01:12 UTC
I do not see port forwarding as a way for exploits. For that you would have to exploit the ssh session first which would give you full access to the shell with the same priviledges and even unconfined by SELinux. You can run your preferred port forwarding method from it as well anyway.

Comment 23 Daniel Walsh 2010-11-30 14:39:16 UTC
If Tomas you are sure that you would need to get full control over the sshd daemon in order to start port forwarding then I can turn it on by default.  But this is a case where I believe we should make ssh selinux aware.  So we could run the process that listens on the wire with one context and the process that actually starts the user shell with a different label.  Then the process that starts the shell could have far greater privs.

Comment 24 John Hein 2010-11-30 16:11:49 UTC
There's no way to get access to ssh port forwarding features without establishing an authenticated session first.  Having port forwarding turned on does not turn sshd into a wide open port forwarding relay.  Or are you (Daniel) mainly concerned about some undiscovered sshd vulnerability or one possibly introduced in the future allowing remote (or local) bypassing of authentication?

That said, I certainly see a potential benefit to having the sshd listening on [default] port 22 run in a different context than the child sshd (or the privilege separated child of that one assuming UsePrivelegeSeparation is turned on).  I'm curious how much rework to the selinux patch is estimated for that task (if someone who is familiar with would be kind enough to provide a WAG)?

Comment 25 Daniel Walsh 2010-11-30 16:43:28 UTC
Yes confining ssh makes no sense, unless you are trying to confine what ssh can do without authentication.  If a vulnerability exists that can bypass authentication, then sshd can execute a shell as unconfined_t or some similar user domain and have great power. 

So I am afraid of a vulnerability in sshd present and future as well as all of the pam modules that sshd loads.  Present and future.

Comment 26 Fedora Admin XMLRPC Client 2011-11-30 12:26:26 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 27 Petr Lautrbach 2012-08-06 07:20:24 UTC
I believe that this is fixed in current F17 release. There is not sshd_forward_ports any longer and since we have SELinux privilege separation, a sshd process responsible for port forwarding is run under SELinux user instead of sshd_t. So if a SELinux user can do bind on a port then he can also create ssh port forward.

Comment 28 Tim Taiwanese Liim 2012-08-08 21:13:40 UTC
Yes, I concur with Petr.  Tried on F17 and sshd port fowarding is
working fine for non-root user.  It looks like port forwarding for
'root' user is still disabled on F17, which I think is a good

Thanks for tracking this issue.

Comment 29 bugreports2005 2012-10-10 13:10:10 UTC
What about chaining X11 forward from one server to another? On RHEL6 I ran into problems with ssh_t on the server in the middle not having permissions to connect to xserver_port_t.

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