whonixcheck Whonix 14 ideas

I was wondering to split-out the Tor bootstrap test of whonixcheck. Make it standalone. (Perhaps later called by whonixcheck.) Had some ideas about whonixcheck long term anyhow. There are too many mixed up use cases, see:

systemcheck - Security Check Application

Maybe only auto running in silent mode and only reporting grave issues. No default active info popups anymore after boot anymore. Silent mode, see:

systemcheck - Security Check Application

And no longer fetching anything from remotes unless whonixcheck is started in a specific mode. (Skipping Tor socks port, Tor trans port [and stream isolation] tests. For better security. [A sane exception for the operating system updates check that just uses apt-get.] At this stage, we no longer need to keep running the leak tests for everyone all the time.

I was also wondering to abolish whonixcheck Whonix News. Info on whonixcheck Whonix News:

Follow Whonix ™ Developments

On one hand, the notification if a Whonix build version had to be deprecated - lets hope this will never happen - but it may happen - is useful. The other news about important things, I am not sure an info line in whonixcheck is an effective means to communicate that. That would require a much better standalone gui notification.

  • We could also if ever needed to deprecate a build version by releasing a whonixcheck Debian package upgrade and issuing a big warning popup. The advantage of having whonixcheck Whonix News not go through apt-get applies to a much lesser degree since now everything is hosted on whonix.org and since there is no Permanent Takedown Attack Defender on the horizon anyhow.

  • Linux distributions have no mechanism to effectively relay important informations to users. By default I would propose an emergency new notification. Lots and lots of Linux desktop users do not continuously follow Linux or their distribution news. Should anything really bad happen such as “debian.org domain down, you will no longer receive upgrades, make sure to read more at …” or “apt-get vulnerability in the wild, do not upgrade using apt-get or you will become infected, read more …”, then I would imagine a non-intrusive “distribution news” popup with this news would be useful with buttons such as “got it, remind me later”. I tried to provide such a mechanism using whonixcheck Whonix News but the gui is much too bad for this to be an effective means of spreading the news.

  • related:

  • apt-revoker - Check for Revocation Certificates before running apt-get - ⚓ T140 apt-revoker - Check for Revocation Certificates before running apt-get

  • Permanent Takedown Attack Defender - ⚓ T114 Permanent Takedown Attack Defender

1 Like

+1 to that[quote=“Patrick, post:1, topic:2456”]
Maybe only auto running in silent mode and only reporting grave issues. No default active info popups anymore after boot anymore. Silent mode, see:
[/quote]
Maybe this could be chosen by the user in the First-Time-Setup (as Whonix/check Verbosity Setting )

I guess its better than nothing , but there should be a standalone gui notification nonetheless (sadly I would also need to teach me gui related stuff)

Need to do some reading on that one

1 Like

Yes then Tor bootstrap could be easily reusable for other things should you need to.

Yes a good idea. IMO only prompt the user if there is something serious instead of bomabrding them with alerts - they will become apathetic and possibly annoyed.

+1 Absolutely. Minimizing the outside connections the system prevents unnecessary risks.

Smart to rely on apt so the notification system is at least as secure as it instead of inventing your own. Permanent Takedown attack resistance and apt fail-safes are possible but its a different discussion.

1 Like

And even when running it as leak test / connectivity test, perhaps IPs should be hidden by default since users tend to post screenshots. I would not know a usable way to re-enable showing the IPs. Command line options and config options are not very usable but perhaps best that can be offered.

More importantly, I have no idea yet how users could start whonixcheck in its different modes. I mean just the general sanity testing that does not connect to external targets (besides operating system updates check using apt-get) vs extended connectivity test / leak test that connects to check.torproject.org. Perhaps two start menu entries.

  • whonixcheck
  • Whonix Leak and extended Connectivity test

Maybe hide the IP by default and only show it if a config or a command line option is present.

This sounds sane ,but I always get a bad feeling when stuff gets simplified and the output hidden .

Offtopic:
Btw I know that there was a Thread about Useability or something and Whonix direction , but what is Whonix main Userbase ( Security Geeks or Privacy Newb’s?)
I would think that there is a majority who cares more about security and is ok with the added “workload” and alerts. ( I believe its better to have a alert to much than one missed)
But as a I2P guy I’m used to be a in the minority. :wink:

1 Like

Offtopic answered here:
upcoming usability improvements that will hurt, TLS downloads, abolishing torrent downloads - #15 by Patrick

And even when running it as leak test / connectivity test, perhaps IPs should be hidden by default since users tend to post screenshots. I would not know a usable way to re-enable showing the IPs. Command line options and config options are not very usable but perhaps best that can be offered.

That’s a “good thing” because it stops users from shooting themselves in the leg. Assuming those who dig into the commandline have a good/informed reason for doing so.

Perhaps two start menu entries.

whonixcheck
Whonix Leak and extended Connectivity test

Sounds good.

1 Like

https://github.com/Whonix/whonixcheck/commit/a4bde61e9622b8776fd7bcc47794d53e493fec4c
https://github.com/Whonix/whonixcheck/commit/abfeec092d2af0f7a4e521175b9c7b546846e92f
https://github.com/Whonix/whonixcheck/commit/9ede77fdda2df67dbfbf048c1123497d5d8d8a9d
https://github.com/Whonix/whonixcheck/commit/dcca948cea7071e2431c7ad9eb7b598b37cd58f6
https://github.com/Whonix/whonixcheck/commit/499d0bdc189fe00b5edee91e984f6303f0c39fd7
https://github.com/Whonix/whonixcheck/commit/95624483864bca097f112aa4de002caf61c5f6e4

1 Like

https://github.com/Whonix/whonixcheck/commit/df8ce7b52c1bde9bbb76f3999567d0e918d8453e

1 Like

https://github.com/Whonix/whonixcheck/commit/71930e80882bc8d62afe674b4a1108aa60946afb

The following ticket required lots of changes in whonixcheck.

iptables block network access until sdwdate succeeded
https://phabricator.whonix.org/T533

//cc @JasonJAyalaP @HulaHoop

https://github.com/Whonix/whonixcheck/commit/58c66f5700f0e90301a9e4d6042f573371671edd

1 Like

https://github.com/Whonix/whonixcheck/pull/8

It may be helpful if usr/lib/whonixcheck/check_tor_config.bsh every time before tor is reloaded or restarted. Because right now, the reload and restart with systemd though execute the verification against tor configs, they only provide a Tor fails start log, which is not as helpful as this one.

iry:

It may be helpful if usr/lib/whonixcheck/check_tor_config.bsh every time before tor is reloaded or restarted. Because right now, the reload and restart with systemd though execute the verification against tor configs, they only provide a Tor fails start log, which is not as helpful as this one.

It’s a cool idea. It could be implemented in ACW? Fits better there?

For systemd we can easily ship a systemd drop-in to call a script before
Tor reload/restart, happy to help with the drop-in.

Or how do users reload/restart Tor? Perhaps information when that fails
should be shown at these places?

1 Like

There will be the same issue with systemd drop-in as before:

PreExec=tor --verify will be executed before our drop-in detailed report. Therefore, when PreExec=tor --verify fails, our drop-in will never get executed.

Then we need to somehow define a new systemd unit file that always gets reload or restarted when another (Tor) systemd unit file gets restarted or reloaded.

/lib/systemd/system/tor@default.service is already using:

PartOf=tor.service
ReloadPropagatedFrom=tor.service

So saybe we can extend /lib/systemd/system/tor.service with ExecStartPre=... systemd unit file drop-in instead.

Btw… The following also stops tor@default.service.

sudo systemctl stop tor.service

Maybe we shouldn’t tell users to engage with sudo systemctl restart tor@default.service directly but use sudo systemctl restart tor.service instead. (And perhaps the .service can be dropped for simplicity.)

2 Likes

Sounds like a good idea to me.

Task created:
http://phabricator.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/T785