{{Header}}
{{title|title=
sdwdate Development Notes
}}
{{#seo:
|description=Fingerprinting versus Security
}}
= chrony as a replacement for sclockadj =
== Introduction ==
Idea: use sdwdate to fetch the time. But set the time using chrony (new method). Instead of using sclockadj (current method).

Problem with [https://github.com/{{project_name_short}}/sdwdate/blob/master/usr/src/sdwdate/sclockadj.c sclockadj] is that it is using clock_settime which is causing issues. chrony is using [https://www.whonix.org/wiki/Dev/TimeSync#Adjusting_time_slowly_using_adjtimex/ntp_adjtime adjtimex] which will probably work better.

For that, chrony is configured in "offline mode". I.e. not contacting any remote servers for fetching the time. Chrony is supposed to be used for setting the time only which sdwdate should feed into chrony through its unix domain socket driver protocol.

== Instructions ==
'''1.''' Platform specific.

* Debian: No special steps required.
* Qubes: Required in Qubes only.

{{CodeSelect|code=
sudo touch /var/run/qubes-service/clocksync
}}

'''2.''' Remove all other time synchronization daemons.

This is to avoid other time synchronization daemons competing for any clock changes.

{{CodeSelect|code=
sudo apt purge ntp* sdwdate systemd-timesyncd
}}

'''3.''' Install chrony.

{{Install Package|package=
chrony
}}

'''4.''' {{Open with root rights|filename=
/etc/chrony/conf.d/30_sdwdate.conf
}}

'''5.''' Paste.

{{CodeSelect|code=
## Enable offline mode.
## Disable Debian default pool.
## Which is configured in /etc/chrony/chrony.conf
## Does not work.
#pool 2.debian.pool.ntp.org offline

## Open the refclock unix domain socket.
## Tested. This is functional. When running "chronyc sources"
## the socket is shown. Versus without the following line, the
## socket is not shown.
refclock SOCK /var/run/chrony.ttyS0.sock
}}

'''6.''' Save and exit.

'''7.''' {{Open with root rights|filename=
/etc/chrony/chrony.conf
}}

Out-comment or delete the following line.

<pre>
pool 2.debian.pool.ntp.org iburst
</pre>

Non-ideal. Would be nicer if configuration of offline mode could be done with a drop-in snippet in folder <code>/etc/chrony/conf.d</code> but this might not be possible.

'''8.''' Save and exit.

'''9.''' Restart chrony.

{{CodeSelect|code=
sudo systemctl restart chrony
}}

'''10.''' No need to restart chronyd. <ref>
Since it is just an alias in <code>/lib/systemd/systemchrony.service</code>.

<pre>
Alias=chronyd.service
</pre>
</ref>

'''11.''' Check if unix domain socket file <code>/var/run/chrony.ttyS0.sock</code> exists.

{{CodeSelect|code=
ls /var/run/chrony.ttyS0.sock
}}

'''12.''' Watch chrony journal log.

{{CodeSelect|code=
sudo journalctl -f -u chrony
}}

'''13.''' Verify that the unix domain socket driver is the only time source.

{{CodeSelect|code=
chronyc sources
}}

Expected printout:

<pre>
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#? SOC0                          0   4     0     -     +0ns[   +0ns] +/-    0ns
</pre>

'''14.''' chronyc

Might be helpful during development.

{{CodeSelect|code=
chronyc
}}

{{CodeSelect|code=
chronyc help
}}

{{CodeSelect|code=
chronyc tracking
}}

'''15.''' See man pages.

* https://manpages.debian.org/chronyd
* https://manpages.debian.org/chronyc
* https://manpages.debian.org/chrony.conf

'''16.''' GNU date usage examples:

Might be useful during development.

To show the current time in unixtime format:

{{CodeSelect|code=
date --utc "+%s"
}}

Expected printout:

<pre>
1654420510
</pre>

To convert a specific time/date to unixtime, use:

{{CodeSelect|code=
date --utc "+%s" --date "Sun 05 Jun 2022 09:22:28 AM UTC"
}}

Expected printout:

<pre>
1654420948
</pre>

'''17.''' TODO: task

Write a python3.9 or bash script that expects unixtime and writes into unix domain socket file <code>/var/run/chrony.ttyS0.sock</code>.

interface draft, TODO:

{{CodeSelect|code=
./unixtime-to-chrony-socket 1654420510
}}

Or if the protocol also supports nanoseconds:

{{CodeSelect|code=
./unixtime-to-chrony-socket 1654420510.864804506
}}

How can we write messages to the unix domain socket file?

maybe https://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer

does not work

== Information ==
Testing if chrony is really in "offline mode" is not trivial. <code>pool 2.debian.pool.ntp.org offline</code> did not work.

chrony needed 7 minutes between its start and showing that it is still communicating with remote time servers.

<pre>
Jun 05 04:46:44 disp5211 systemd[1]: Starting chrony, an NTP client/server...
Jun 05 04:46:44 disp5211 chronyd[6133]: chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Jun 05 04:46:44 disp5211 chronyd[6133]: Frequency -0.343 +/- 9.106 ppm read from /var/lib/chrony/chrony.drift
Jun 05 04:46:44 disp5211 chronyd[6133]: Using right/UTC timezone to obtain leap second data
Jun 05 04:46:44 disp5211 chronyd[6133]: Loaded seccomp filter
Jun 05 04:46:44 disp5211 systemd[1]: Started chrony, an NTP client/server.
Jun 05 04:53:52 disp5211 chronyd[6133]: Selected source 172.107.94.157 (2.debian.pool.ntp.org)
Jun 05 04:53:52 disp5211 chronyd[6133]: System clock TAI offset set to 37 seconds
</pre>

----

= Fingerprinting versus Security =
An optimization problem.  There are conflicting goals.

* goal: Saving remote server resources &rarr; implementation: use <code>HEAD</code> (implemented)
** (similar to <code>curl --head HEAD</code>)
** is what sdwdate uses.
** [https://gitlab.tails.boum.org/tails/tails/-/issues/5924 Tails discussed using <code>GET</code> instead of <code>HEAD</code> for Tails <code>htpdate</code> but rejected that.]
* goal: Fingerprinting resistance at remote server level. &rarr; implementation: Hide outdated user agent version numbers (not implemented)
** similar to <code>--user-agent curl</code> or even a fake user agent.
** Disadvantage being that this user agent makes use really unique.
** Hiding version number might not help with security either. If a user was running a vulnerable version, an adversary could just try out every exploit independent of version number in user agent. The only solution are timely software upgrades by the user.
** [https://lists.autistici.org/thread/20121015.131424.1e9070fd.gl.html#i20121015.131424.1e9070fd Tails-dev - Faking htpdate user agent worth it?]
* goal: Maximization of security of sdwdate (implemented) &rarr; implementation: use most remote code execution resistant backend (such as <code>curl</code> vs full web browser vs python3 requests) for <code>url_to_unixtime</code>
** Use python3 requests since (implemented in memory safe python3 code) instead of curl (implemented in unsafe memory language C).
* goal: Maximization of fingerprinting resistance from viewpoint of remote server &rarr; implementation: emulate being a full browser by using selenium or similar. (not implemented)
** Convincingly emulating being a browser is impossible. Changing the user agent is insufficient. The only way of convincingly emulating being a browser is to actually run a browser.
** Running a full browser inside sdwdate however would mess up security. Also very difficult to implement. Running a full browser GUI with an invisible X server and then somehow only exacting HTTP DATE header from the GUI. Also might actually worsen the web fingerprint of sdwdate since sdwdate would fetch and run any tracking (google analytics) script that the remote server has. Then also which browser? Tor Browser + selenium? Keep that browser updated. Seems way too complex to implement.

A compromise had to be made. Priority goals had to be chosen. Maximization of security of sdwdate and saving remote server resources was chosen.

= sdwdate linux user account =

* sdwdate is a daemon designed to be executed by an init system.
* There is <u>no</u> hard dependency on systemd by sdwdate.
* Currently there is only a systemd unit file in the sdwdate github repository.
* Other systems could be supported in principle too but this is currently [[unsupported]] because no contributor has contributed that functionality.
** What would be needed is to (at least minimally) port https://github.com/{{project_name_short}}/sdwdate/tree/master/usr/lib/systemd/system to a different init system such as SysVinit.
* sdwdate designed to run under linux user account <code>sdwdate</code>.
* Running sdwdate as root is neither desired nor required.
* Thanks to systemd, sdwdate can benefit from systemd sandboxing which would be unavailable if starting sdwdate manually under the same privileges as the user.
** Using Linux capabilities. Has <code>AmbientCapabilities=CAP_SYS_TIME</code> and <code>CapabilityBoundingSet=CAP_SYS_TIME</code>. Therefore linux user account <code>sdwdate</code> can set the time without any requirement for root.

= Footnotes =
{{reflist|close=1}}

{{Footer}}

[[Category:Design]]