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.

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.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE

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.

http://manpages.ubuntu.com/manpages/xenial/man1/sntp.1.html

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.

In T691#13739, @JasonJAyalaP wrote:

http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE

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)?

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

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

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).