On Tue, 25 Feb 2020, 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.
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.
That all sounds like a lot of work, especially since some of those files are
created by other programs on the fly. Eg. /dev/pps[0-9] are created by some
module and may not exist until just before chrony is started.
Maybe it would help if you could explain in what cases it's useful to start
chronyd without root privileges?
Starting chronyd without being root minimizes the actions performed by this
user this is a way to ensure the reduction of the attack surface.
There are no actions needed to be performed by the user. And this is why
chrony maintains root only for long enough to perform the actions and then
gives up root. If the writer of chrony is careful, the attack surface is
minimal already. For some things root is the simplest thing to use, and other
methods, by increasing complexity increase the probabily for bugs, potentially
with security implications.
I would be happy to modify the patch to best meet the needs of the upstream.
On 2/24/20 9:37 AM, Miroslav Lichvar wrote:
On Mon, Feb 24, 2020 at 09:17:46AM +0100, Nicolas Bouchinet wrote:
Linux distributions that use systemd can delegate those security tasks to
systemd unit configuration rules.
```
User=chrony
AmbientCapabilities=CAP_SYS_TIME
CapabilityBoundingSet=CAP_SYS_TIME
```
Those indicative and non exhaustive configuration options ensure chrony is
directly executed as unprivileged user, therefore reducing the attack
surface.
The trouble with that approach is that it works only with some
specific configurations. chronyd needs the root privileges for other
things than just adjusting the clock, which cannot be done by systemd.
Please see a previous discussion:
https://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/msg01731.html
