On Tue, Feb 25, 2020 at 08:48:07AM +0100, Nicolas Bouchinet wrote:
> I allow myself to answer the questions asked during the previous discussion.
>
> > Capabilities are needed to bind to a privileged port and adjust the system
> > clock, but chronyd does other things on start that require root
> privileges,
> > e.g. create /var/{run,lib,log}/chrony, open /dev/pps*, /dev/ptp*, /dev/rtc
> > and possibly other devices.
>
> As I see it, access to devices can be set by the chrony distribution package
> maintainer using UNIX group permissions.
How would you know which devices chronyd will need to open? I wouldn't
want chronyd to have permissions to open a PPS, RTC, or other devices
when it's not configured to use them.
You would need to parse the configuration file and understand what
chronyd will do.
> Also the creation of /var/{run,lib,log}/chrony can be handled by systemd
> using the {Runtime,State,Logs}Directory unit configuration options.
> I can inquire other cases that needs root privileges.
It would also need the CAP_NET_BIND_SERVICE and CAP_NET_ADMIN
capabilities, depending on the configuration.
> Starting chronyd without being root minimizes the actions performed by this
> user this is a way to ensure the reduction of the attack surface.
I'm not convinced. To me it looks like chronyd starting without root
actually needs to have more permissions and capabilities than it
usually needs, possibly increasing impact of a vulnerability.
My suggestion would rather be to review the code that runs before the
root privileges are dropped. It's not a lot of code.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
