On Sat, Sep 12, 2015 at 10:30:05PM +1200, Bryan Christianson wrote: > When a user is specified to chronyd (command line or config file), chronyd > will drop privileges, restoring them when required for privileged system > calls.
If chronyd is allowed to restore the root privileges (i.e. set the effective UID/GID back to root) to make the adjtime() or settimeofday() system call and the chronyd process is compromised, the attacker can simply call seteuid() to get the root privileges at any time, or not? On systems where it's not possible to adjust the clock without the root privileges, there is a possibility to separate the privileges in multiple processes, like openntpd does for instance. One process keeps the root privileges to adjust the clock and the other processes send commands to it over pipe or socket. Of course, the protocol the processes use to communicate with each other needs to be simple and carefully implemented so the root process can't be exploited through it. Implementing that in chronyd is possible, but it may require some major changes in the design. If chronyd did this on Mac OS X, which doesn't have readonly adjtime(), the clock precision would probably get much worse as every reading of the remaining adjustment would require a context switch to the root process and back. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
