Bug 1118758

Summary: Add validator for ssh port to only accpet "22" or "1024-65535"
Product: [Retired] oVirt Reporter: haiyang,dong <hadong>
Component: ovirt-nodeAssignee: Douglas Schilling Landgraf <dougsland>
Status: CLOSED WONTFIX QA Contact: bugs <bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 3.5CC: bugs, cshao, didi, dougsland, fdeutsch, gklein, gouyang, huiwa, leiwang, mgoldboi, ovirt-bugs, rbalakri, s.kieske, ycui, yeylon
Target Milestone: ---   
Target Release: 3.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: node
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-20 13:13:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1085907    
Bug Blocks:    

Description haiyang,dong 2014-07-11 13:15:31 UTC
Description of problem:
For example, if input "1023" for ssh port, after configured,
try login rhevh via ssh:
[root@agent2 ovirt-node]# ssh admin.73.241 -p 1023
ssh: connect to host 10.66.73.241 port 1023: Connection refused

so we need add validator for ssh port to only accpet "22" or "1024-65535"


Version-Release number of selected component (if applicable):
ovirt-node-iso-3.5.0.ovirt35.20140707.el6.iso

How reproducible:
100%


Steps to Reproduce:


Actual results:


Expected results:


Additional info:

Comment 1 Fabian Deutsch 2014-07-14 13:20:15 UTC
What is the cause? Why can't ssh connect to sshd on port 1023?

Comment 2 Douglas Schilling Landgraf 2014-07-14 14:01:24 UTC
This is cause because we must setup ssh_port_t type before restarting sshd.

# semanage port -a -t ssh_port_t  -p tcp 1023
<configure ssh to new port>
# restart ssh daemon

After that, we are ok. I am preparing a patch for this.
Anyway, haiyang thanks for your efforts.

Please let me know your thoughts.

Comment 3 Sven Kieske 2014-07-14 14:08:46 UTC
Port 1023 is reserved for future use, are you prepared to change your
port when iana assigns this port to something else?

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

Comment 4 Douglas Schilling Landgraf 2014-07-14 14:30:54 UTC
Hi Sven,

(In reply to Sven Kieske from comment #3)
> Port 1023 is reserved for future use, are you prepared to change your
> port when iana assigns this port to something else?
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-
> port-numbers.txt

Agreed but I do believe haiyang,dong used as example for low ports, he could be used let's say '30' port.

Comment 5 Sven Kieske 2014-07-14 14:59:32 UTC
Yes, but I don't understand your reasoning at all.

Fabian asked:

Why can't ssh connect to sshd on port 1023?

You gave an technical answer to an organizational problem:

Yes you can't connect to ssh on this port because you need a proper selinux
rule first.

But even with this selinux rule you _must_ _not_ connect to this port, because
these ports are reserved by iana.

Thus haiyang,dong came up with the solution already:

so we need add validator for ssh port to only accpet "22" or "1024-65535"

(and add the correct selinux configuration for the given port).

Comment 6 Fabian Deutsch 2014-07-14 16:56:56 UTC
Hey, thanks for the vivid input everybody.

My thoughts actually addressing this bug:
1. Are firewall rules permitting the access?
2. Is selinux permitting the access?
3. Is the port used otherwise?

A more high level questions, what ports we want to allow. Initially I thought that we should leave it to the administrator to choose any port he wants.
But now I believe that Sven has a point, and that we should not allow to bind to privileged ports.

This is what the patch currently addresses.

Besides that the other points (1-3) should also be checked when the user enters a port. Please consider this in the patch as well.

Comment 7 Douglas Schilling Landgraf 2014-07-15 02:31:33 UTC
(In reply to Fabian Deutsch from comment #6)
> Hey, thanks for the vivid input everybody.
> 
> My thoughts actually addressing this bug:
> 1. Are firewall rules permitting the access?
> 2. Is selinux permitting the access?
> 3. Is the port used otherwise?
> 
> A more high level questions, what ports we want to allow. Initially I
> thought that we should leave it to the administrator to choose any port he
> wants.
> But now I believe that Sven has a point, and that we should not allow to
> bind to privileged ports.
> 
> This is what the patch currently addresses.

Initially I thought as you Fabian that's why I was about to address in different approach. However, let's start with haiyang's suggestion and if users start requesting low ports we create a new discussion.

> 
> Besides that the other points (1-3) should also be checked when the user
> enters a port. Please consider this in the patch as well.

Agreed. I am going to review the suggestion.

Comment 8 Fabian Deutsch 2014-07-24 16:02:19 UTC
This is a mass change, moving bugs of merged patches into MODIFIED.

Please correct the state, if you think that the move was not justified.

Comment 9 Sandro Bonazzola 2014-10-17 12:14:10 UTC
Moving pending bugs not fixed in 3.5.0 to 3.5.1.

Comment 10 Sandro Bonazzola 2015-01-21 16:08:01 UTC
oVirt 3.5.1 has been released, re-targeting to 3.6.0 as not marked as urgent / high severity or priority

Comment 11 Yedidyah Bar David 2015-06-14 06:03:57 UTC
(In reply to Sven Kieske from comment #3)
> Port 1023 is reserved for future use, are you prepared to change your
> port when iana assigns this port to something else?
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-
> port-numbers.txt

Also port 1027 is reserved for future use. Not sure why should there be a difference. Although there are different processes for registering ports in the various relevant ranges, they can still be reserved.

We should not stop users choosing whatever ports they feel like.

We should recommend and default to assigned ports.

Just the same way as any other sane service, such as common web/mail servers.

Comment 13 Fabian Deutsch 2015-07-20 13:13:37 UTC
I agree with comment 11. Closing thereof.