Henry:
Could Whonix keep this flexibility and still allow only certified applications in a “walled garden” version?
Yes.
“wallet garden” mode would only be activated if some condition is met.
[1] Under consideration I have kernel parameters and/or Qubes qvm
service files.
To get back to flexibility: disable “walled garden” - which would mean
disable that kernel parameter and/or Qubes qvm service.
[1] In a later version these conditions could be set by default.
One form of a non-contentious implementation of “wallet garden” for
example would be if a Qubes-Whonix VM on Qubes with the appendix
-only-torbrowser in its VM name could result in user user only being
able to run torbrowser and no other application. Or perhaps a qvm
service “allow-torbrowser” would be better. It’s just brainstorming at
this stage. First, identify ways a user can run an application: a
terminal emulator or better said shell, dom0 qvm-run, … Qubes gives a
lot flexibility. Perhaps at boot time /usr/bin and others could be made
unreadable for user user using linux user permission access rights.
The tool how to disable “walled garden” could be along the lines “better
don’t this today if the first time you got the idea of doing this,
research this using search engines, don’t run commands you don’t
understand, ask multiple people for advice on this”. Advanced users
could always have a one or two clicks “yes, i know what I am doing,
disable wallet garden and never ask me again”.
(All presupposes integration with
GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup)
Of course new threats or anything crafted for a specific target will not be affected by that. Handling known threats will already be an important step.
Handling known threads sounds like signature detection which sounds like
antivirus. Now, making Whonix into a signature chasing project is
unsustainable. Others have failed to do so. If anywhere, antivirus would
be a better place to try that. See also on why antivirus are failing
concept: