Bug 629348 - selinux prevents sshd from listening on alternate reserved port
Summary: selinux prevents sshd from listening on alternate reserved port
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot-plugins
Version: 13
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-01 18:14 UTC by James Ralston
Modified: 2010-09-11 08:57 UTC (History)
3 users (show)

Fixed In Version: setroubleshoot-plugins-2.1.61-1.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-11 08:57:37 UTC


Attachments (Terms of Use)
full message from sealert (2.48 KB, text/plain)
2010-09-03 15:06 UTC, James Ralston
no flags Details

Description James Ralston 2010-09-01 18:14:12 UTC
sshd listens on port 22 (and only port 22) by default, but can be configured to listen on any number of arbitrary ports in sshd_config(5).

On several of my systems, I have configured sshd to listen on a reserved port (that is, one less than 1024) other than port 22. This is because I want to hide sshd from ankle-biting script kiddies that swarm the Internet looking for ssh daemons to brute-force or otherwise attack, but I don't want to run sshd on a high port that any random user can bind to.

However, the SELinux targeted policy blocks sshd from listening on any port less than 1024 other than 22, even when run by root.

Try as I might, I cannot fathom the motivation for this restriction. What is it?

For now, I am setting the "allow_ypbind" SELinux boolean to true, which disables the restriction on sshd binding on a reserved port other than 22. But from inspecting the selinux-policy source RPM, setting allow_ypbind to true also permits a vast swath of other bindings that I don't need and don't want.

Therefore, please either remove the restriction on sshd binding on reserved ports other than 22, or else provide a new SELinux boolean (e.g., allow_sshd_bind_reserved) that will permit sshd to bind on any reserved port when set to true.

(Alternate suggestions are welcome, but these are the two most reasonable courses of action that I can think of.)

Thank you.

Comment 1 Daniel Walsh 2010-09-01 19:52:07 UTC
# semanage port -a -t ssh_port_t -p tcp 1023

I googled for sshd listening on different port selinux

And I came up with

http://equivocation.org/node/124

Sadly I did not write it.

Comment 2 James Ralston 2010-09-01 22:48:59 UTC
Ah, but sealert only suggests twiddling the allow_ypbind boolean. That's why I didn't explore other possible ways to permit sshd to bind to alternate ports.

If it is reasonable to do so, it would be a good thing to have sealert suggest:

/usr/sbin/semanage port -a -t ssh_port_t -p tcp DENIED_PORT

Even a suggestion like "the semanage command can also be used to permit this access; please read the man page for examples" would be helpful...

Comment 3 Daniel Walsh 2010-09-02 15:47:10 UTC
Could you attach the actual avc message that you got and I will look to see why that suggestion came up.

Comment 4 James Ralston 2010-09-03 15:06:09 UTC
Created attachment 442919 [details]
full message from sealert

Here's the complete message from sealert.

Note that this line:

[sshd has a permissive type (sshd_t). This access was not denied.]

...is absolutely wrong; SELinux was in enforcing mode and (correctly) denied the access:

$ getenforce 
Enforcing

$ grep sshd /var/log/messages
2010-09-03T10:57:40.584263-04:00 example sshd[21944]: error: Bind to port 822 on 0.0.0.0 failed: Permission denied.
2010-09-03T10:57:40.584631-04:00 example sshd[21944]: error: Bind to port 822 on :: failed: Permission denied.
2010-09-03T10:57:40.584923-04:00 example sshd[21944]: fatal: Cannot bind any address.

Comment 5 Daniel Walsh 2010-09-03 19:22:08 UTC
The permissive line is keyed off of success=yes in the AVC.  Which means the system service returned success

Fixed the bind_connect.py plugin to match on hi_reserved_port_t in 

setroubleshoot-plugins-2.1.61-1.fc13

Comment 6 Fedora Update System 2010-09-03 19:41:04 UTC
setroubleshoot-plugins-2.1.61-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/setroubleshoot-plugins-2.1.61-1.fc13

Comment 7 Fedora Update System 2010-09-04 05:01:35 UTC
setroubleshoot-plugins-2.1.61-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setroubleshoot-plugins'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/setroubleshoot-plugins-2.1.61-1.fc13

Comment 8 James Ralston 2010-09-05 04:24:49 UTC
Yes, that's much better; positive karma added to bodhi. Thanks!

Comment 9 Fedora Update System 2010-09-11 08:57:33 UTC
setroubleshoot-plugins-2.1.61-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


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