Bug 653579

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):


Summary:

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) 2.6.35.6-48.fc14.i686 #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)

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

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.

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.

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.

Can we add a comment line in the config mentioning this then?

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.

(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?

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.

*** Bug 656813 has been marked as a duplicate of this bug. ***

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.

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.

Read 

http://danwalsh.livejournal.com/23944.html

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.

Thinking of it more I agree that the ssh port forwarding SELinux boolean should be on by default in the targeted policy.

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.

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.

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.

I believe ssh -X -Y remhost works without SELinux allowing port forwarding.

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.

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).

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.

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.

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)?

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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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.

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
practice.

Thanks for tracking this issue.

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.