3 ms·

> 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 behavi

> 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.
- foldr 4y ago
  >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. Only if you're using a web server that's prepackaged by the distro.
  - ehutch79 4y ago
    If you're installing third party services, and exposing them to the internet, or even local networks, it's not out of line to expect you to know what you're doing. At least enough to turn off the 'dont shoot yourself in the foot' protections
    - foldr 4y ago
      People who "don't know what they're doing" will just disable SELinux if it's too difficult to configure the policy that they want. It's better to make security policies easy to configure correctly so that more people do it correctly. Also, what does "third party" really mean in this context? I am neither the author of the Linux distro that I'm using nor the web server that I want to use. It's all third party software from my point of view.
      - ehutch79 4y ago
        You need some level of expertise to turn off selinux, or even know what it is. They know what they're doing enough to know the consequences if they can turn it off. By third party, i mean stuff not in the distro. It's extra effort to install something else. You're likely to have at least a link to docs in your face when you went and got the binaries.
  - throwaway09223 4y ago
    Every casual user is using a distro packaged version. That's why distros exist. If you're doing your own packaging then presumably you know how to invoke the server by creating a service file for systemd.
antimeme 4y ago
Stop pretending that non-technical users want to run web servers. That's just not a thing. What you're actually arguing is that some technical users are so important that making them tweak a default setting is too much to ask, but others are so insignificant that pulling the rug out from under them after decades of practice is perfectly reasonable. I disagree. Do you not grasp WHY Let's Encrypt requires port 80 (for one particular challenge type)? Think about that for just one second. Okay I'll spell it out for you: the convention that ports under 1024 are privileged gives Let's Encrypt some confidence that privileged ports runs services sanctioned by the system administrator and not some tenant -- which is exactly the point I was making. So thanks for providing more support for my argument, I guess? And while we're at it, can we stop pretending you care about user experience? You can't even be bothered to type those two words! You cite no studies and make no technical arguments. All you're offering is the claim that the default you prefer "should be preferred" based on your intuition. I probably shouldn't even dignify your claim that people think port numbers in URLs mean they're being attacked with a response, but I'll bite. Do you have even a shred of evidence for this claim or did you just make it up on the spot? Obviously the latter, but if even if it were true the solution would be to educate people about what port numbers mean. Unless you want to argue that any feature of any internet service some people are confused about should be abolished? I guess we'll have to shut the entire internet down. Changing the port number is a perfectly reasonable solution for many use cases, but it's far from the only option. Alternatives include CAP_NET_BIND_SERVICE, net.ipv4.ip_unprivileged_port_start, port mapping in containers and many more. Pick your favorite and stop wasting everyone's time.

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.

foldr 4y ago
>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. Only if you're using a web server that's prepackaged by the distro.
- ehutch79 4y ago
  If you're installing third party services, and exposing them to the internet, or even local networks, it's not out of line to expect you to know what you're doing. At least enough to turn off the 'dont shoot yourself in the foot' protections
  - foldr 4y ago
    People who "don't know what they're doing" will just disable SELinux if it's too difficult to configure the policy that they want. It's better to make security policies easy to configure correctly so that more people do it correctly. Also, what does "third party" really mean in this context? I am neither the author of the Linux distro that I'm using nor the web server that I want to use. It's all third party software from my point of view.
    - ehutch79 4y ago
      You need some level of expertise to turn off selinux, or even know what it is. They know what they're doing enough to know the consequences if they can turn it off. By third party, i mean stuff not in the distro. It's extra effort to install something else. You're likely to have at least a link to docs in your face when you went and got the binaries.
- throwaway09223 4y ago
  Every casual user is using a distro packaged version. That's why distros exist. If you're doing your own packaging then presumably you know how to invoke the server by creating a service file for systemd.

antimeme 4y ago

Stop pretending that non-technical users want to run web servers. That's just not a thing. What you're actually arguing is that some technical users are so important that making them tweak a default setting is too much to ask, but others are so insignificant that pulling the rug out from under them after decades of practice is perfectly reasonable. I disagree. Do you not grasp WHY Let's Encrypt requires port 80 (for one particular challenge type)? Think about that for just one second. Okay I'll spell it out for you: the convention that ports under 1024 are privileged gives Let's Encrypt some confidence that privileged ports runs services sanctioned by the system administrator and not some tenant -- which is exactly the point I was making. So thanks for providing more support for my argument, I guess? And while we're at it, can we stop pretending you care about user experience? You can't even be bothered to type those two words! You cite no studies and make no technical arguments. All you're offering is the claim that the default you prefer "should be preferred" based on your intuition. I probably shouldn't even dignify your claim that people think port numbers in URLs mean they're being attacked with a response, but I'll bite. Do you have even a shred of evidence for this claim or did you just make it up on the spot? Obviously the latter, but if even if it were true the solution would be to educate people about what port numbers mean. Unless you want to argue that any feature of any internet service some people are confused about should be abolished? I guess we'll have to shut the entire internet down. Changing the port number is a perfectly reasonable solution for many use cases, but it's far from the only option. Alternatives include CAP_NET_BIND_SERVICE, net.ipv4.ip_unprivileged_port_start, port mapping in containers and many more. Pick your favorite and stop wasting everyone's time.