To be clean, I'm all for the systemd hardening. I'm just reporting a
case where the current configuration appears to have a gap. I'm in
agreement that the DAC_OVERRIDE may be too big of a hammer, but I wasn't
able to quickly identify another alternative without switching to the
AmbientCapabilities path.
The nsd daemon provides config file inclusion support, however a mixed
file ownership as I had becomes nonfunctional. It was non-intuitive to
me that the nsd daemon, running as the nsd user, didn't have permissions
to read files owned by the nsd user. During investigation I figured out
that the systemd initially launches as root and then setuid to nsd. The
workaround was ensuring that the base config and all included data files
are owned by root, but perhaps there's a cleaner way to support this.
Joel
On 2019-09-03 12:39, Markus Schade wrote:
Hi Joel,
thanks for the report.
The systemd service file has been in part of the package for 5 years,
with the default ordering of sections (unit, service, install).
The upstream service while was more less recently added (~1 year ago).
Since systemd hardening has been available and recommended, the
corresponding directives where added from upstream.
Admittedly this still requires some fine tuning such as:
https://salsa.debian.org/dns-team/nsd/merge_requests/1
As such, I am a bit reluctant to ship, use or patch around the upstream
service file.
However the DAC_OVERRIDE capability is quite excessive as is bypasses
all permission checks. Giving the process this capability would be the
quite contrary to the intent of settting CapabilityBoundingSet.
Best regards,
Markus
