5 ms·

This article is nonsense. Privileged ports are a security feature. They have literally nothing to do with mainframes. On multi-user systems, they're incredib

This article is nonsense. Privileged ports are a security feature. They have literally nothing to do with mainframes. On multi-user systems, they're incredibly important because they give external clients confidence that the services provided on them are authorized by the system and not just by any user -- some of whom may not be as trustworthy as others. Most systems in this era of cheap hardware are single user, BUT NOT ALL SYSTEMS. It's fine for Windows and Mac OS to do without them and it's fine to configure your own Linux system to disable them if that's what you want, but it's completely insane to argue that they're a security flaw because some people work around them using insecure practices. There are plenty of secure ways to work around them, most obviously by USING A NON-PRIVILEGED PORT. Start your service on port 8080, for example, and give out a URL like http://example.com:8080/path http://example.com:8080/path. It's really that simple. Take the time to understand the actual purpose of a feature before urging others to abolish it.

_nalply 4y ago
You mean that you don't want all users who can login on your system to start something that listens on a port below 1024. I can understand that.
threatripper 4y ago
One example I can think of is a local server handling some sensitive stuff. E.g. a webserver for a CNC machine that takes a password to log in. If that webserver is offline another user could start their own webserver with a fake login prompt. Other users who go to http://localhost http://localhost as usual would not notice.
im3w1l 4y ago
Now anyone can snipe 8080 and steal the url you "gave out". How is that secure?
- antimeme 4y ago
  Did you... actually read the article this comment responded to? Or even the comment you're replying to? The original article proposed making all ports non-privileged because most systems serve a single user in practice. Are you really going to argue that changing the port to 8080 is insecure because someone could snipe it but making all ports non-privileged is better because... now someone can snipe 80 as well?
  - im3w1l 4y ago
    I agree with the article that privileged ports is a bad idea. I disagree that making them free for all, or using a free-for-all port is a good solution. You propose it as a simple solution but it has many issues.
benob 4y ago
Could the os restrict a range of ports to a non-root user? That would cover your concerns, wouldn't it?
- INTPenis 4y ago
  They did, it's called 1025-65535. This is literally ancient tech. There are more modern (and perhaps more granular) ways to do it today with cgroups and nftables I'm sure. I myself am an avid SElinux user and I know for sure you can restrict ports to user roles there.
  - BossingAround 4y ago
    What resources did you use to get into SELinux? I am an SELinux user, but it's more like "I can debug it and make it work without turning it off".
    - INTPenis 4y ago
      I have the book SElinux by example which is still very relevant. But these days I'd say you can get all the same info online[1]. 1. https://github.com/SELinuxProject/selinux-notebook https://github.com/SELinuxProject/selinux-notebook
nailer 4y ago
Can we just make socket permissions like files? chown mike /dev/tcp/80
- _ph_ 4y ago
  Right, that's the way it should be done for ports that try to listen to non-local connections. That would actually strongly increase security, as non-privileged ports can be abused a lot too.
foldr 4y ago
This was covered in the article, albeit a little sarcastically: >And for the three folks in Finland who administer multi-user Linux instances and rely on privileged ports for their mainframe-era security properties, they can always run sysctl and set their port limit to 1024 as it was before. If you wanted to block non-root users binding certain ports, you'd still be able to do so. It just doesn't make sense to have this as the default anymore, as it tends to cause more security issues that it prevents.
- antimeme 4y ago
  Not a LITTLE sarcastically, no. No one has yet provided evidence that privileged ports create even a single security issue. While there's lots of huffing and puffing in the original article (including someone confusing privileged ports with IP based authentication, which is effectively dead), the closest it gets is to say that dropping privileges in a server is a pain. And then they go on to show off a one line configuration change that would disable privileged ports system wide. So do that if it makes sense for you. What doesn't make sense would be to abandon decades of practice that real people (more than three in Finland, actually) rely upon because some people are too lazy to make a trivial change to their systems. And let's get real: 99.9% of people are never going to want to run a web server on their computers. You're just arguing that your portion of that 0.1% -- let's be a LITTLE sarcastic and call them five penguins in Antarctica! -- are more important than the rest.
  - foldr 4y ago
    If the best you can say for the current defaults is that they're easy to change, then it's probably time to change the defaults. The article doesn't just say that dropping privileges is a 'pain', but points out that a security model based on binding a port as root (or another specially privileged user) and then dropping privileges has been a persistent source of security issues. The article links to several detailed explanations of this (e.g. https://wibblement.blogspot.com/2021/11/the-persistent-idiocy-of-privileged.html https://wibblement.blogspot.com/2021/11/the-persistent-idioc..., https://www.staldal.nu/tech/2007/10/31/why-can-only-root-listen-to-ports-below-1024/ https://www.staldal.nu/tech/2007/10/31/why-can-only-root-lis...). The one-line configuration change also doesn't work well if the service is executed via an interpreter or VM. Authbind also has its edge cases: https://www.reddit.com/r/golang/comments/cqlpnq/comment/ewyluyh/ https://www.reddit.com/r/golang/comments/cqlpnq/comment/ewyl...
ttiurani 4y ago
> Most systems in this era of cheap hardware are single user, BUT NOT ALL SYSTEMS OP quite clearly argues that multi-user systems can still have the old behavior if they so choose with explicit configuration. OP makes an argument about what should be the sensible default in 2022, and who should do explicit configuration. I think the point that nowadays easy single user linux configuration should be preferred over multi-user configurations is good. IMO distros could make this easy by turning privileged ports into an (advanced) installation question. Then the clearly single-user-focused distros would default to 80, and the more server-oriented or conservative distros would default to the current behavior, but both could do which ever. > Start your service on port 8080, for example. In the era of Let's Encrypt, this is really about 80 and 443. The background for the OP is probably to host "normal" sites on single user hardware. If you were to give out to non-technical users addresses like "http://example.org:8080 http://example.org:8080" which then transform into "https://example.org:8443 https://example.org:8443", that's just horrible UX. Those kinds of numbers in the URL probably also look to many people like someone is trying to hack them. Furthermore addresses are also communicated word-of-mouth "go to example dot org". So no, using unprivileged ports is not an actual workaround for the use cases OP is referring to.
- throwaway09223 4y ago
  I think you're missing the fact that in your scenario services are started with explicit privileges by init. This has nothing to do with unprivileged login users. Back in the day, init ran as root. Init ran services as root, and services were responsible for becoming another user if they didn't need root after binding a port. It was a very simple interface. Nowadays we have much more complicated interfaces and as a result more flexibility. Init (now systemd) must still run as root, but we can tell the component that executes a service to drop privileges before the service is started. These privileges are also more granular: Root is no longer needed to bind to a low port: We only have to grant the CAP_NET_BIND capability, rather than running as a root user. On top of this we now have network namespaces and containers, so services might be granted their own interfaces visible only to that service, with specific permissions tailored to only that service. If you are running a persistent webserver you do not need to worry about whether or not unprivileged users can bind to port 443. The webserver is managed by init and the permissions granted to services are explicit and granular -- and typically all this is configured by the distro by default.
bArray 4y ago
> It's fine for Windows and Mac OS to do without them and it's fine to configure your own Linux system to disable them if that's what you want, but it's completely insane to argue that they're a security flaw because some people work around them using insecure practices. I guess we will also be making distros with `sudo` without a password to stop some people writing insecure scripts that try to pass it via plaintext stdin. This should be default for _every_ Linux system because some Linux server admins copy insecure code from StackOverflow. /s
mattpallissard 4y ago
Agreed. In the HPC and research space large multi user systems are still king. It's quite common for users to stand up their own versions of privileged services on unprivileged ports. Bad actors aside, this prevents users from accidentally mimicking a service that would effectively break shared resources. These are nice guardrails. Security and guardrails should be optional, but it should be opt out, not opt in.

_nalply 4y ago

You mean that you don't want all users who can login on your system to start something that listens on a port below 1024. I can understand that.

threatripper 4y ago

One example I can think of is a local server handling some sensitive stuff. E.g. a webserver for a CNC machine that takes a password to log in. If that webserver is offline another user could start their own webserver with a fake login prompt. Other users who go to http://localhost http://localhost as usual would not notice.

im3w1l 4y ago

Now anyone can snipe 8080 and steal the url you "gave out". How is that secure?

antimeme 4y ago
Did you... actually read the article this comment responded to? Or even the comment you're replying to? The original article proposed making all ports non-privileged because most systems serve a single user in practice. Are you really going to argue that changing the port to 8080 is insecure because someone could snipe it but making all ports non-privileged is better because... now someone can snipe 80 as well?
- im3w1l 4y ago
  I agree with the article that privileged ports is a bad idea. I disagree that making them free for all, or using a free-for-all port is a good solution. You propose it as a simple solution but it has many issues.

benob 4y ago

Could the os restrict a range of ports to a non-root user? That would cover your concerns, wouldn't it?

INTPenis 4y ago
They did, it's called 1025-65535. This is literally ancient tech. There are more modern (and perhaps more granular) ways to do it today with cgroups and nftables I'm sure. I myself am an avid SElinux user and I know for sure you can restrict ports to user roles there.
- BossingAround 4y ago
  What resources did you use to get into SELinux? I am an SELinux user, but it's more like "I can debug it and make it work without turning it off".
  - INTPenis 4y ago
    I have the book SElinux by example which is still very relevant. But these days I'd say you can get all the same info online[1]. 1. https://github.com/SELinuxProject/selinux-notebook https://github.com/SELinuxProject/selinux-notebook

nailer 4y ago

Can we just make socket permissions like files? chown mike /dev/tcp/80

_ph_ 4y ago
Right, that's the way it should be done for ports that try to listen to non-local connections. That would actually strongly increase security, as non-privileged ports can be abused a lot too.

foldr 4y ago

This was covered in the article, albeit a little sarcastically: >And for the three folks in Finland who administer multi-user Linux instances and rely on privileged ports for their mainframe-era security properties, they can always run sysctl and set their port limit to 1024 as it was before. If you wanted to block non-root users binding certain ports, you'd still be able to do so. It just doesn't make sense to have this as the default anymore, as it tends to cause more security issues that it prevents.

antimeme 4y ago
Not a LITTLE sarcastically, no. No one has yet provided evidence that privileged ports create even a single security issue. While there's lots of huffing and puffing in the original article (including someone confusing privileged ports with IP based authentication, which is effectively dead), the closest it gets is to say that dropping privileges in a server is a pain. And then they go on to show off a one line configuration change that would disable privileged ports system wide. So do that if it makes sense for you. What doesn't make sense would be to abandon decades of practice that real people (more than three in Finland, actually) rely upon because some people are too lazy to make a trivial change to their systems. And let's get real: 99.9% of people are never going to want to run a web server on their computers. You're just arguing that your portion of that 0.1% -- let's be a LITTLE sarcastic and call them five penguins in Antarctica! -- are more important than the rest.
- foldr 4y ago
  If the best you can say for the current defaults is that they're easy to change, then it's probably time to change the defaults. The article doesn't just say that dropping privileges is a 'pain', but points out that a security model based on binding a port as root (or another specially privileged user) and then dropping privileges has been a persistent source of security issues. The article links to several detailed explanations of this (e.g. https://wibblement.blogspot.com/2021/11/the-persistent-idiocy-of-privileged.html https://wibblement.blogspot.com/2021/11/the-persistent-idioc..., https://www.staldal.nu/tech/2007/10/31/why-can-only-root-listen-to-ports-below-1024/ https://www.staldal.nu/tech/2007/10/31/why-can-only-root-lis...). The one-line configuration change also doesn't work well if the service is executed via an interpreter or VM. Authbind also has its edge cases: https://www.reddit.com/r/golang/comments/cqlpnq/comment/ewyluyh/ https://www.reddit.com/r/golang/comments/cqlpnq/comment/ewyl...

ttiurani 4y ago

> Most systems in this era of cheap hardware are single user, BUT NOT ALL SYSTEMS OP quite clearly argues that multi-user systems can still have the old behavior if they so choose with explicit configuration. OP makes an argument about what should be the sensible default in 2022, and who should do explicit configuration. I think the point that nowadays easy single user linux configuration should be preferred over multi-user configurations is good. IMO distros could make this easy by turning privileged ports into an (advanced) installation question. Then the clearly single-user-focused distros would default to 80, and the more server-oriented or conservative distros would default to the current behavior, but both could do which ever. > Start your service on port 8080, for example. In the era of Let's Encrypt, this is really about 80 and 443. The background for the OP is probably to host "normal" sites on single user hardware. If you were to give out to non-technical users addresses like "http://example.org:8080 http://example.org:8080" which then transform into "https://example.org:8443 https://example.org:8443", that's just horrible UX. Those kinds of numbers in the URL probably also look to many people like someone is trying to hack them. Furthermore addresses are also communicated word-of-mouth "go to example dot org". So no, using unprivileged ports is not an actual workaround for the use cases OP is referring to.

throwaway09223 4y ago
I think you're missing the fact that in your scenario services are started with explicit privileges by init. This has nothing to do with unprivileged login users. Back in the day, init ran as root. Init ran services as root, and services were responsible for becoming another user if they didn't need root after binding a port. It was a very simple interface. Nowadays we have much more complicated interfaces and as a result more flexibility. Init (now systemd) must still run as root, but we can tell the component that executes a service to drop privileges before the service is started. These privileges are also more granular: Root is no longer needed to bind to a low port: We only have to grant the CAP_NET_BIND capability, rather than running as a root user. On top of this we now have network namespaces and containers, so services might be granted their own interfaces visible only to that service, with specific permissions tailored to only that service. If you are running a persistent webserver you do not need to worry about whether or not unprivileged users can bind to port 443. The webserver is managed by init and the permissions granted to services are explicit and granular -- and typically all this is configured by the distro by default.

bArray 4y ago

> It's fine for Windows and Mac OS to do without them and it's fine to configure your own Linux system to disable them if that's what you want, but it's completely insane to argue that they're a security flaw because some people work around them using insecure practices. I guess we will also be making distros with `sudo` without a password to stop some people writing insecure scripts that try to pass it via plaintext stdin. This should be default for _every_ Linux system because some Linux server admins copy insecure code from StackOverflow. /s

mattpallissard 4y ago

Agreed. In the HPC and research space large multi user systems are still king. It's quite common for users to stand up their own versions of privileged services on unprivileged ports. Bad actors aside, this prevents users from accidentally mimicking a service that would effectively break shared resources. These are nice guardrails. Security and guardrails should be optional, but it should be opt out, not opt in.