[defect]: insecure systemd service files

[g0tar]

What type of defect/bug is this?

Unexpected behaviour (obvious or verified by project member)

How can the issue be reproduced?

Hello,

I've noticed that 24d97aa introduced near-full-root caps:

User=radiusd
AmbientCapabilities=[...] CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE

I'm not sure, so I'd like to ask - are they being handled (actively dropped) by radiusd in runtime?
If not, arent't they retained during all the process lifetime, effectively being even worse than starting as root and changing to radiusd by the daemon itself?

Note that AmbientCapabilities= implicitly enables keep-caps securebits (man systemd.exec).
Then, according to man 7 capabilities:

SECBIT_KEEP_CAPS

              [...] However, if
              the thread has set this flag and its effective UID is
              already nonzero, and the thread subsequently switches all
              other UIDs to nonzero values, then the effective
              capabilities will not be cleared.

Anyway - even when there's no issue here, these caps are not required by the server itself, unless configured in such way. E.g.:

• CAP_SETUID/CAP_SETGID - might be required when server was configured with
  user/group = different_than_radiusd_specified_in_service_unit.
  This should be fixed by directly specifying proper user/group in service unit (drop-in).
• CAP_CHOWN CAP_DAC_OVERRIDE - required by sloppy deployments, disregarding proper file permissions. Or when configured to use passwd/shadow directly.

None of those should be supported in default installations.
Not by AmbientCapabilities= anyway, as it's better off starting as root followed by setuid() (unless caps are handled in daemon itself).

Log output from the FreeRADIUS daemon

Whatever...

Relevant log output from client utilities

No response

Backtrace from LLDB or GDB