caddy 2.6.4 package setcaps directly

Is this a new report?

Yes

System Info

Void 6.3.6_1 x86_64 AuthenticAMD uptodate F

Package(s) Affected

caddy-2.6.4_2

Does a report exist for this bug with the project's home (upstream) and/or another distro?

Possibly not, it's directly related to the package's INSTALL file using setcap, which contradicts recommended operational practices.

Expected behaviour

caddy, when started by activating it in /var/service, should be able to open privileged ports such as 443 and 80, but it should not grant this permission to users in general.

Actual behaviour

When the caddy package is installed (does not even need to run), can squat on privileged ports as it has a capabilities directly set on the binary.

Steps to reproduce

Have a Caddyfile with the contents:

http://localhost:23 {
        root * /tmp
        file_server browse
}

caddy run --config ./Caddyfile then happily starts a server on port 23, when started as a normal user. (With an already running caddy with an enabled admin port, a minimal addition is needed for success)

I don't think this is desirable. Other distributions normally use systemd to grant this capability only the caddy service installed/started by the system, not to the installed binary.

I recommend dropping the INSTALL file with setcap, and instead of chpst (as it doesn't seem to be capabilities aware), perhaps use setpriv for a similar effect:

exec setpriv --reuid caddy --regid caddy --clear-groups \
  --ambient-caps -all,+net_bind_service \
  --inh-caps -all,+net_bind_service \
  --bounding-set -all,+net_bind_service \
  --no-new-privs -- caddy run ${OPTS} --config ${CONFFILE:-/etc/caddy/Caddyfile}

This has been tested to provide functionality matching the current setup when run via a /var/service link, but not allowing any user to squat unused privileged ports with a configuration in their control.

Start by locating the caddy package's INSTALL file and the service entry point used through /var/service; inspect how setcap and chpst currently grant port-binding capability. Compare that flow with the reported setpriv command and verify that an installed caddy binary cannot bind privileged ports directly while the service still can.