4 ms·
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 user
by 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 agoIf 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 agoPeople 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 agoYou 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 agoEvery 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.
- foldr 4y agoI don't think this is true in general. For example, in one instance I wanted to use caddy, which wasn't packaged for CentOS at the time. I don't think I had trouble getting it to run as a non-root user, but getting it to work with SELinux was a big PITA. The Linux community seems to have a pervasive "if you're doing X then you should be able to Y" kind of attitude. But sometimes you just need to do X, and you know what you know.
- throwaway09223 4y agoThat's totally unrelated to the topic of how services are invoked. SELinux is indeed a PITA. I usually just turn it off. Your complaint about the community says more about you than about the community. It's certainly not true as a rule.