Information
ID: 383
PHID: PHID-TASK-2645u7pj52vcu5gvyfme
Author: Patrick
Status at Migration Time: wontfix
Priority at Migration Time: Normal
Description
After running.
timedatectl set-ntp 1
The following link will be created:
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service
cat /lib/systemd/system/systemd-timesyncd.service
sudo service systemd-timesyncd status
Debian does not enable systemd-timesyncd by default yet. (Related to T382.)
We could ship a systemd drop-in file to prevent start of systemd-timesyncd even if it was enabled.
/lib/systemd/system/systemd-timesyncd.service.d/40_disable.conf (untested, but doable)
## This file is part of Whonix.
## Copyright (C) 2012 - 2015 Patrick Schleizer <adrelanos@riseup.net>
## See the file COPYING for copying conditions.
[Unit]
ConditionPathExists=!/usr/share/whonix
(Or some more clever, better configurable condition.)
Into which package would this belong? Not into sdwdate, because packages are not supposed to break other packages if deliberately installed at the same time by the system administrator. [Would make the page unfit for inclusion into official Debian.] [Or at least this would have to be carefully crafted using Breaks: or some mechanism of that kind.]
How useful is it to preemptively disable services the user or distribution could enable at some point?
In Whonix 12’s whonixcheck we will have a sanity check anyway. (T332)
On the other hand, we have the anon-banned-package, which bans a few packages. How useful would it be to expand this? Would we then need to add ntp, chrony, tlsdate also? How realistic and useful is it to preemptively preventing users being up to such things from doing this?
At the moment I tend to believe, it’s best to not over engineer this. Make sure such stuff is tested for, not part of images and part of unit testing.
Comments
HulaHoop
2015-07-28 18:03:52 UTC
Patrick
2015-07-28 18:14:55 UTC