5 ms·

Apache needs to start as `root` but then drops to an non-privileged user. systemd's `User=<user>` can't really express that. Perhaps an option that says a uni

by ape4 5y ago

Apache needs to start as `root` but then drops to an non-privileged user. systemd's `User=<user>` can't really express that. Perhaps an option that says a unit needs to be root until the first fork when it has to be a specified user. `ForkUser=apache`

candiddevmike 5y ago
It only needs to root to bind to privileged ports I believe. You should be able to use a non-root user and give it CAP_NET_BIND_SERVICE: [Service] AmbientCapabilities=CAP_NET_BIND_SERVICE
- ape4 5y ago
  Cool! But then I suppose the forked processes could then bind to a low numbered port - something they can't do now. So Apache would have to make sure to revoke that capability when forking.
  - 5e92cb50239222b 5y ago
    You could combine it with something like this SocketBindDeny=any SocketBindAllow=tcp:80 SocketBindAllow=tcp:443 These ports should be denied by the kernel because they're already taken by httpd, and all other will be denied by bpf filters installed by systemd. It feels like plugging holes in a dam, but that's what you do with popular operating systems.
5e92cb50239222b 5y ago
I don't know about httpd specifically, but many applications want root only to be able to bind to a privileged port (like :80). This can be circumvented in one of a few ways: 1. add this to .service AmbientCapabilities=CAP_NET_BIND_SERVICE 2. or listen on :8080 and use NAT: iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080 3. or make the port unprivileged sysctl -w net.ipv4.ip_unprivileged_port_start=80 It may work for httpd too, I haven't tested it.
- Un1corn 5y ago
  The correct Systemd solution would be to create a socket unit but your solutions works without modifying the service code
  - Spivak 5y ago
    I can't find anything for an officially supported for Apache or Nginx to support inetd/systemd socket activation bit it certainly would be nice.
  - growse 5y ago
    I think this requires support from the service, no? Not everything that wants to open up a port seems to support socket activation. I tried with 6tunnel and couldn't get it to work.
    - _0w8t 5y ago
      systemd provides a workaround in the form of systemd-socket-proxyd [1]. Granted it copies data, but when the max performance is not required, it works. Sometimes services allow to be configured to listen UNIX socket path, then systemd-socket-proxyd allows to disable ip address access by forwarding the network socket to that. [1] https://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html https://www.freedesktop.org/software/systemd/man/systemd-soc...
- marcosdumay 5y ago
  Apache also uses the start user to read stuff like TLS private keys, that its normal user does not have access to.
  - VTimofeenko 5y ago
    It's possible to remove the root requirement for this through systemd's credentials mechanisms: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Credentials https://www.freedesktop.org/software/systemd/man/systemd.exe...
staticassertion 5y ago
This is one of the main problems with "whole program sandboxes". Many times a program only needs permissions right at the start and then never again. From the outside though there's no way to signal "OK, I'm done, lock me down" for most sandboxing systems. One approach that may work with systemd is to have two processes. One would be a broker, running as root. It would grab a port, for example. The other process would be spawned by the broker as a limited service and inherit that port from the parent, with no permissions of its own to open it, only to inherit. IDK how to express that in systemd-land though. At that point you might be better off just writing the code to sandbox things yourself.
eliaspro 5y ago
Many applications don't need to bind the port themselves but will happily accept one passed to them during process invocation. This allows to let systemd to manage ports using socket units which will also stay up and buffer requests when restarting a service, allow service activation on demand/incoming requests or per connection service instances, e.g. for better isolation of sshd's per connection/user.
pquerna 5y ago
hello. i added support for httpd to support systemd socket activation in 2013: https://svn.apache.org/viewvc?view=revision&revision=1511033 https://svn.apache.org/viewvc?view=revision&revision=1511033 httpd can start as non-root, assuming other configurations like the access / error logs are writable by the non-root user.

by ape4 5y ago

candiddevmike 5y ago

It only needs to root to bind to privileged ports I believe. You should be able to use a non-root user and give it CAP_NET_BIND_SERVICE: [Service] AmbientCapabilities=CAP_NET_BIND_SERVICE

ape4 5y ago
Cool! But then I suppose the forked processes could then bind to a low numbered port - something they can't do now. So Apache would have to make sure to revoke that capability when forking.
- 5e92cb50239222b 5y ago
  You could combine it with something like this SocketBindDeny=any SocketBindAllow=tcp:80 SocketBindAllow=tcp:443 These ports should be denied by the kernel because they're already taken by httpd, and all other will be denied by bpf filters installed by systemd. It feels like plugging holes in a dam, but that's what you do with popular operating systems.

5e92cb50239222b 5y ago

I don't know about httpd specifically, but many applications want root only to be able to bind to a privileged port (like :80). This can be circumvented in one of a few ways: 1. add this to .service AmbientCapabilities=CAP_NET_BIND_SERVICE 2. or listen on :8080 and use NAT: iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080 3. or make the port unprivileged sysctl -w net.ipv4.ip_unprivileged_port_start=80 It may work for httpd too, I haven't tested it.

Un1corn 5y ago
The correct Systemd solution would be to create a socket unit but your solutions works without modifying the service code
- Spivak 5y ago
  I can't find anything for an officially supported for Apache or Nginx to support inetd/systemd socket activation bit it certainly would be nice.
- growse 5y ago
  I think this requires support from the service, no? Not everything that wants to open up a port seems to support socket activation. I tried with 6tunnel and couldn't get it to work.
  - _0w8t 5y ago
    systemd provides a workaround in the form of systemd-socket-proxyd [1]. Granted it copies data, but when the max performance is not required, it works. Sometimes services allow to be configured to listen UNIX socket path, then systemd-socket-proxyd allows to disable ip address access by forwarding the network socket to that. [1] https://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html https://www.freedesktop.org/software/systemd/man/systemd-soc...
marcosdumay 5y ago
Apache also uses the start user to read stuff like TLS private keys, that its normal user does not have access to.
- VTimofeenko 5y ago
  It's possible to remove the root requirement for this through systemd's credentials mechanisms: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Credentials https://www.freedesktop.org/software/systemd/man/systemd.exe...

staticassertion 5y ago

This is one of the main problems with "whole program sandboxes". Many times a program only needs permissions right at the start and then never again. From the outside though there's no way to signal "OK, I'm done, lock me down" for most sandboxing systems. One approach that may work with systemd is to have two processes. One would be a broker, running as root. It would grab a port, for example. The other process would be spawned by the broker as a limited service and inherit that port from the parent, with no permissions of its own to open it, only to inherit. IDK how to express that in systemd-land though. At that point you might be better off just writing the code to sandbox things yourself.

eliaspro 5y ago

Many applications don't need to bind the port themselves but will happily accept one passed to them during process invocation. This allows to let systemd to manage ports using socket units which will also stay up and buffer requests when restarting a service, allow service activation on demand/incoming requests or per connection service instances, e.g. for better isolation of sshd's per connection/user.

pquerna 5y ago

hello. i added support for httpd to support systemd socket activation in 2013: https://svn.apache.org/viewvc?view=revision&revision=1511033 https://svn.apache.org/viewvc?view=revision&revision=1511033 httpd can start as non-root, assuming other configurations like the access / error logs are writable by the non-root user.