The idea of privileged ports is deprecated

Latest response

Once upon a time, the original idea of high and low (< 1024) ports was a... well, good one, I guess.


The idea was that, when a service was running on a low port, the service must have been started by the administrator of that system, so that service must be deemed safe.


Obviously, with networking changing over the last 20 years or so (rise of the internet et all), this idea has been deprecated for at least 10 of those years.


A service with normal user permissions should therefor be allowed to run on sockets < 1024. This prevents deamons such as sendmail of needing a SUID bit, even though it'll drop privileges as soon as it has the socket.


I'm a bit uncertain how safe it will be to break this assumtion.. It will allow ordinary users to start listeners on port 23/tcp, 22/tcp, 21/tcp or similar and sniff passwords, possibly stealing these ports from these services in the race when yum restart the service during upgrades.


Probably better to start using file capabilities to allow select applications to bind to low ports without running as root (setpcaps cap_net_bind_service+eip /path/to/executable).

If another process is binding to port 23/tcp, 22/tcp, or 21/tcp, no other application can listen unless you are root and it's listening on the ethernet device for all traffic.


I agree that the idea of privledged ports is obsolete.


It's just security through obscurity, which has no business in Linux.

This is the exact thing SELinux is there to prevent. For an appication to bind to sshd_port_t, the application should have the right context.


Password authentication is also obsolete by the way.


And I agree applications should use capabilities. See my other "idea for RHEL7":

I don't disagree that security contexts are the best move here.  However, there are still people running SELinux in permissive, and there will be other reasons not to drop the legacy tradition of privileged ports.  There are also several ways to start select services as non-privileged users on privileged ports than with sid.  I think that's a red herring.


I know this is not a good reference, but Microsoft took that same view in NT5.1, and we all know how that turned out.  Even NT has MAC/RBAC (atlhough virtually no one writes to it, including Microsoft's own developers).  I'd say leave them in, and address the code in programs that still require the suid approach.