sdwdate sclockadj change time without spamming logs

[phabricator-migrator]

Information

ID: 691
PHID: PHID-TASK-vmidlkqnbjnc6lw6rgvo
Author: JasonJAyalaP
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

libc functions that set the time also report the time change in the system log. Making many small changes via sclockadj (which uses clock_settime) spams the logs. NTP subtly changes the time by adjusting the clock frequency with the ntp_adjtime function call.

1. Is there a way to use functions like clock_settime without reporting to the log?

2. Could we install ntpd, but only use it locally and manually? (Sdwdate calculates the date, but then tells ntpd what to do)

3. Is it possible to reimplement what ntp does (which is use ntp_adjtime and related functions and monitor their progress, I think. It’s beyond my C skills). How much would it cost to hire a programmer to do this?

Comments

---

s.sh

2017-06-16 14:07:33 UTC

Is there a way to use functions like clock_settime without reporting to the log

There are generally three ways:

1. Hook into the related library call and prevent the syscall function from being called.
2. Immediately after writing to system logs following a call to clock_settime() make the appended logs removed.
3. During the time of calling clock_settime(), disable the syslog at system level, after returning from the aforementioned function re-enable logging.

First solution:
After some reverse engineering I noticed the logging is done AFTER invoking the corresponding system call (i.e in the kernel space) and not explicitly by calling the syslog library function. So implementing this solution is not straightforward for the case.

Second solution:
You can do this by simply running some bash commands after the call to clock_settime(). But this kind of solution is a little bit dirty however it works. If you want I can prepare a demo code for you to see.

Third solution:
This would cause a race condition and during the short time the function is running some other logs from other sources may fail to be written properly into the log files. However the probability is low.

---

Patrick

2017-06-16 15:15:56 UTC

s.sh (ssh):

s.sh added a comment.

Is there a way to use functions like clock_settime without
reporting to the log

There are generally three ways:

1. Hook into the related library call and prevent the syscall
   function from being called. 2. Immediately after writing to system
   logs following a call to clock_settime() make the appended logs
   removed. 3. During the time of calling clock_settime(), disable the
   syslog at system level, after returning from the aforementioned
   function re-enable logging.

That’s all too hacky.

Also for anti-fingerprinting solutions it would be better to avoid
clock_settime which no other time synchronization software (ntpd,
chrony, systemd-timesyncd) is using and rather emulate a popular one.

Is there a way to use functions like clock_settime without reporting to the log?

Probably not.

Could we install ntpd, but only use it locally and manually? (Sdwdate calculates the date, but then tells ntpd what to do)

This would be a very good solution but not sure it’s possible.

Is it possible to reimplement what ntp does (which is use ntp_adjtime and related functions and monitor their progress, I think.

This would be the next best solution.

Let’s see. There might be someone capable to implement this.

---

JasonJAyalaP

2017-06-16 22:20:58 UTC

5. How does it work?

When ntp needs to adjust more than 128ms, it uses settimeofday to make one big jump.

Under 128ms, it uses adjtimex for small adjustments. Then ntp_adjtime for tuning the kernel’s clock.

If attacks can’t fingerprint us under 128ms, we could just change the time with one big jump. No different from ntpd.

SNTP (simple ntp, part of the ntp package) can be set (forced?) (according to the manpage) to only use the big jump (settimeofday) or adjtimex.

Ubuntu Manpage: sntp - standard Simple Network Time Protocol client program

Options:

1: If no fingerprinting, just make sdwdate set the date via sudo bash

2: Hire some guy to rip out the code in sntp

3: LOL → Make sdwdate run a fake ntp server locally, run sntp manually (sntp -Ss localhost:666), turn off server.

---

Patrick

2017-06-16 23:30:09 UTC

! In T691#13739, @JasonJAyalaP wrote:
5. How does it work?

That sounds rather complicated, no?

When ntp needs to adjust more than 128ms, it uses settimeofday to make one big jump.

Is NTP on Debian really doing that? Says Different operating systems provide different means, but the most popular ones are listed below. Never saw this on Debian. Needs empiric research.

If attacks can’t fingerprint us under 128ms

That’s not clear.

2: Hire some guy to rip out the code in sntp

sntp isn’t popular (not the default anywhere). How popular is NTP vs chrony vs systemd-timesyncd? Is systemd-timesyncd the new Default in Debian stretch? That code might be a lot simpler? Perhaps we could interface with that?

3: LOL → Make sdwdate run a fake ntp server locally, run sntp manually (sntp -Ss localhost:666), turn off server.

It’s not a bad idea. I guess simulating a NTP server could be quite difficult as well. Perhaps run a regular NTP server but modify it to take not a atomic clock, but sdwdate as time source? I.e. simulate an atomic clock instead (or something else that a NTP server accepts as time source)?

---

JasonJAyalaP

2017-06-20 20:16:02 UTC

Removing Whonix 14 tag. It’s not necessary to block 14.

---

Patrick

2017-06-22 10:33:58 UTC

For now, I remain positive this can and should be sorted out for Whonix 14.

---

Patrick

2018-07-25 06:39:27 UTC

This is sorted in a later version of systemd.

option to disable systemd's “Time has been changed” message spam in journal log · Issue #5207 · systemd/systemd · GitHub

---

marmarek

2018-09-18 01:55:54 UTC

Actually, the “apt-daily.timer: Adding 1h 17min 24.927437s random time” message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).