Also whonixcheck needs read access to /home/user/tor-browser_en-US/Docs/sources/versions because it checks Tor Browser's version.

timesync / sdwdate: It depends. On boot, sdwdate starts on its own (by /etc/init.d/sdwdate). One could have timesync uninstalled and sdwdate would still work. (I plan to make these two separate packages. When timesync is manually started, it restarts and monitors sdwdate, hence the confusion. Also since sdwdate dispatches parts of timesync if available. Perhaps I must clean up the implementation, but it works fine for now.) However, /usr/bin/sdwdate needs a profile upon start.

(If you don't believe me or want to test it, edit /usr/bin/sdwdate and add a "echo test > /home/user/sdwdatetest" below "#!/bin/bash". - I guess it would be able to do this unauthorized write.)

Since sdwdate is a deamon, I am not sure if we need to edit it's init script. For example the /etc/init.d/tor (you can look at it on Whonix-Gateway) has native support for AppArmor. I am not sure, if we would need to do this for sdwdate as well. Probably not. Probably a profile for /usr/bin/sdwdate would be sufficient (I guess AppArmor doesn't really care if an init script or user starts an application).

Also whonixcheck needs read access to /home/user/tor-browser_en-US/Docs/sources/versions because it checks Tor Browser's version.

Added /home/user/tor-browser_en-US/Docs/sources/versions. There was /home/user/tor-browser_en-US/Docs/version already in the profile. A bit confusing. I'll test it with whonixcheck --verbose to make sure.

Quote

timesync / sdwdate: It depends. On boot, sdwdate starts on its own (by /etc/init.d/sdwdate). One could have timesync uninstalled and sdwdate would still work. (I plan to make these two separate packages. When timesync is manually started, it restarts and monitors sdwdate, hence the confusion. Also since sdwdate dispatches parts of timesync if available. Perhaps I must clean up the implementation, but it works fine for now.) However, /usr/bin/sdwdate needs a profile upon start.

Added the profile for sdwdate. I first added 'USE_AA_EXEC="yes"' in '/etc/init.d/sdwdate', but since it starts as a deaemon at boot, it is not needed, it is automatically enforced.

I think I mentioned it before. I the Gateway, system_tor in no longer confined since Whonix 8. Ran 'aa-enforce system_tor' and it still does not show in the list of enforced profiles. I did not take the time to check further. I will.

Adding 'USE_AA_EXEC="yes"' to sdwdate's init script is most likely indeed not required. (FYI: 'USE_AA_EXEC="yes"' isn't a magic word. Just a standard shell script variable. It would require additional implementation to react depending on the contents of USE_AA_EXEC, you can see this in Tor's init script if you search that script for USE_AA_EXEC.)

Only issue I am experiencing is, when I run "sudo service sdwdate restart" with the sdwdate profile enabled, I don't see the timesync gui anymore. Maybe I see the gui but the progress meter doesn't move. Or the progress meter moves, but it doesn't close when it reached 100%. This doesn't happen when the sdwdate profile is disabled. Without any denied messages, any idea how to fix it?

Only issue I am experiencing is, when I run "sudo service sdwdate restart" with the sdwdate profile enabled, I don't see the timesync gui anymore. Maybe I see the gui but the progress meter doesn't move. Or the progress meter moves, but it doesn't close when it reached 100%. This doesn't happen when the sdwdate profile is disabled. Without any denied messages, any idea how to fix it?

It seems that the normal behavior when running "sudo service sdwdate restart" is that it does not show the timsesync progress window. There is no reference to timesync in the sdwdate scripts in /etc/init.d/ or /usr/bin/, and sdwdate on its own does not display anything.

From the test I have done, when you start or reboot the workstation, the gui will show after "sudo service sdwdate restart" only during the first sleeping period. After that, the gui is no longer displayed, regardless of the apparmor mode (enforce or disable). Just a guess, but it could have something to do with sdwdate running as a daemon and timesync on its own, in parallel. Aren't both basically achieving the same thing?

It seems that the normal behavior when running "sudo service sdwdate restart" is that it does not show the timsesync progress window.

You can test on a fresh Whonix-Workstation 8 without any AppArmor profiles, if you run "sudo service sdwdate" restart you always get a progress bar window and the progress bar moves.

Quote

There is no reference to timesync in the sdwdate scripts in /etc/init.d/ or /usr/bin/, and sdwdate on its own does not display anything.

/etc/init.d/sdwdate and /usr/bin/sdwdate indeed do not include any GUI specific code. This is on purpose. The GUI code is implemented in /etc/sdwdate.d/31_timesync_plugin.

sdwdate `eval`uates the contents of $DISPATCH_PRE, which is for example "/usr/lib/whonix/timesync_pre --autostart --mode startup".

Quote

From the test I have done, when you start or reboot the workstation, the gui will show after "sudo service sdwdate restart" only during the first sleeping period.

This is on purpose. This has to do with --mode startup vs. --mode daemon. When sdwdate starts after reboot or after sdwdate was upgraded by apt-get, $SDW_MODE will be startup. After the first run, next $SDW_MODE will be daemon. This because the user is advised to wait until sdwdate succeeded after the first boot of Whonix for better anonymity. When exactly subsequent runs of sdwdate are executed and how long they take is not so important. It only tries to avoid clock skews and long time likeability. For subsequent runs, sdwdate would only show if sdwdate failed. You can test that on a separate Whonix-Workstation without any AppArmor profiles, when no Whonix-Gateway is available for this Whonix-Workstation, the daemon sdwdate will fail and it's timesync plugin will launch a popup notification.

Another way to test sdwdate error handling is to run "sudo touch /var/lib/sdw_error", after end of current sleep and in the next loop the the daemon an error will be provoked. In the log you will see.

6b170e95-07ee-47fe-b1d0-375e99f705fc: dispatching post_error (SDW_MODE: startup): /usr/lib/whonix/timesync_post_error "$error_message" & disownAnd also a popup will be shown. (This command /usr/lib/whonix/timesync_post_error "$error_message" can also be used standalone for testing purposes.)

Quote

Aren't both basically achieving the same thing?

No. In essence, for one there is sdwdate, a standalone daemon which has been extended with a timesync plugin. From sdwdate perspective, the sdwdate plugin is used to inform terminal and X users about important events that would otherwise go unnoticed in syslog.

When timesync is started, it watches sdwdate's log and runs "sudo service sdwdate restart", keeps the user informed about sdwdate's progress and status independently from sdwdate. (Manually run timesync would be able to diagnose sdwdate failures and bugs.)

for i in /etc/sdwdate.d/*; do if [ -f "$i" ]; then ## If the last character is a ~, ignore that file, because it was created ## by some editor, which creates backup files. if [ "${i: -1}" = "~" ]; then continue fi ## Skipping files such as .dpkg-old and .dpkg-dist. if ( echo "$i" | grep -q ".dpkg-" ); then true "skip $i" continue fi source "$i" fidone

## In case sdwdate did not succeed, for example one pool was unreachable. #eval $DISPATCH_POST_FAILURE

SDW_MODE="daemon"

sleep 15

done

This is what sdwdate basically does while leaving out the actual time synchronization code. You can use this for testing. Either to just look it at it as a reference how it's working, or to write a profile for /usr/bin/sdwdate_simulator (just to find out what's missing in the actual sdwdate profile), or use this code to temporarily replace the actual /usr/bin/sdwdate to make debugging the AppArmor profile easier.

I think it would be best if sdwdate was allowed to exec all /usr/lib/whonix/timesync_... scripts unconstrained by AppArmor profiles while also preserving the environment variables. I don't think these scripts have potential to be exploited. I think what they need is unconstrained execute mode (ux) but I don't know enough about AppArmor. This is because the /usr/lib/whonix/timesync_... scripts need lots of permissions for themselves for notification stuff which may not be allowed by the current sdwdate AppArmor profile.

I think it would be best if sdwdate was allowed to exec all /usr/lib/whonix/timesync_... scripts unconstrained by AppArmor profiles while also preserving the environment variables. I don't think these scripts have potential to be exploited. I think what they need is unconstrained execute mode (ux) but I don't know enough about AppArmor. This is because the /usr/lib/whonix/timesync_... scripts need lots of permissions for themselves for notification stuff which may not be allowed by the current sdwdate AppArmor profile.

I have authorized all /usr/lib/whonix/timesync_... scripts, including the ones not required by apparmor plus msgcollector and msgprogress, to run unconfined.

/usr/lib/whonix/timesync_pre rwUx,/usr/lib/whonix/timesync_post_error rwUx,/usr/lib/whonix/timesync_prerequisite rwUx,/usr/lib/whonix/timesync_post_success rwUx,/usr/lib/whonix/usr/timesync_init_d rwUx,/usr/lib/whonix/usr/timesync_post_failure rwUx,/usr/lib/whonix/msgcollector rUx,/usr/lib/whonix/msgprogress rUx,To no avail. I had actually started in that direction.

In order to make a fresh start, all the profiles were moved in a tmp directory. Run “sudo service apparmor teardown” for good measure.