[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

preventing Qubes-Whonix updates through clearnet on Qubes R4 / ensuring torified updates

root issue:

https://github.com/QubesOS/qubes-issues/issues/3118

impact:

Users who clone whonix-gw or whonix-ws, will quite likely either not know they have to edit /etc/qubes-rpc/policy/qubes.UpdateProxy or forget about it.

workaround:

I am not sure what @marmarek will decide wrt https://github.com/QubesOS/qubes-issues/issues/3118 and when the solution flows into Qubes.

Meanwhile I would like to add a workaround. Please check the implementation.

Latest /etc/uwt.d/40_qubes.conf (just small changes, refactoring, output).

https://github.com/Whonix/qubes-whonix/blob/master/etc/uwt.d/40_qubes.conf

A safer workaround would be a Qubes-Whonix TemplateVM firewall that block access to Qubes updates proxy.

(https://github.com/Whonix/qubes-whonix/blob/master/usr/lib/qubes-whonix/init/torified-updates-proxy-check would have to run under a special user that may circumvent the firewall.)

All of this is done. Qubes TemplateVMs whonix-gw and whonix-ws will now use Whonix-Workstation firewall. (whonix-gw template will use it as well since the whonix-gw template is “actually more like a workstation”)

whonix-gw-firewall / whonix-ws-firewall package got merged into a single package whonix-friewall. Tons of commits.

So now even if https://github.com/QubesOS/qubes-issues/issues/3118 does not get implemented or not so soon, it got much harder to update over clearnet. It is still possible to update over clearnet with manual reconfiguration, and good that this flexibility and freedom exists.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]