Customizing Whonix Firewall / torified dom0 upgrades

Do changes to /etc/whonix_firewall.d/50_user need to be made in the TemplateVM to be persistent?

I don’t believe that /etc/whonix_firewall.d is a bind-directory. Thanks.

Edit by Patrick:
changed title

Yes.

Or create a standalone VM.

Disabled Transparent TCP, Transparent DNS. Everything works except one thing.

I want to perform Template VM updates over Tor. Whonix-Gateway is set as NetVM.
All Whonix Templates & Default Fedora Template updates are working.

However, ‘sudo qubes-dom0-update’ times out because it can not resolve http://yum.qubes-os.org
Dom0 uses Default Fedora Template VM as its UpdateVM (would like to use Whonix-Gateway but RPM is required)
Then the Fedora Template VM is connected to Whonix-Gateway.

This setup worked before switching to TransTCP,DNS. Would solution require wrapping qubes-dom0-update somehow?

Yes.

Debugging hints…

bash -x qubes-dom0-update

You see, it runs:

/usr/lib/qubes/qubes-download-dom0-updates.sh

So you could try wrap it through torsocks or uwt. Either by editing qubes-dom0-update or qubes-download-dom0-updates.sh. qubes-dom0-update seems more appropriate to me.

But you may run into another missing Qubes feature preventing you from this. Namely…
“Make it possible to use Debian VM as UpdateVM for downloading dom0 updates”:

Since Whonix is based on Debian, that feature is also missing there.

Thanks for the pointers. It appears to be working.

I installed torsocks in UpdateVM (Default Fedora Template in my case)
Edited torsocks.conf to route to 10.137.4.1: 9104
Added torsocks to qvm-run in qubes-dom0-update.
Traffic is routing through tor & successful result.

However, generating 40-50
WARNING torsocks[2588]: [syscall] Unsupported syscall number 188. Denying the call (in tsocks_syscall() at syscall.c:465)
Both syscall number 188 and 191.
Hopefully, these are harmless like : [Whonix-devel] torsocks: How to hide 'Unsupported syscall number' messages?

If Debian/Whonix were supported already, I would say consider porting it to uwt. For better stream isolation. Also because it stops the warning spam by setting the right environment variables.

[code] ## Disable torsocks warning spam such as.

[May 20 11:45:27] WARNING torsocks[2645]: [syscall] Unsupported syscall number 224. Denying the call (in tsocks_syscall() at syscall.c:165)

⚓ T317 disable torsocks warning spam

export TORSOCKS_LOG_LEVEL=1
[/code]

[quote=“entr0py, post:3, topic:1356”]Disabled Transparent TCP, Transparent DNS. Everything works except one thing.

I want to perform Template VM updates over Tor. Whonix-Gateway is set as NetVM.
All Whonix Templates & Default Fedora Template updates are working.

However, ‘sudo qubes-dom0-update’ times out because it can not resolve http://yum.qubes-os.org
Dom0 uses Default Fedora Template VM as its UpdateVM (would like to use Whonix-Gateway but RPM is required)
Then the Fedora Template VM is connected to Whonix-Gateway.

This setup worked before switching to TransTCP,DNS. Would solution require wrapping qubes-dom0-update somehow?[/quote]

A simple way I do Dom0 updates over Tor is put a Fedora ProxyVM in-between Dom0 and Whonix-Gateway.

Dom0 → Fedora ProxyVM → Whonix-Gateway ProxyVM

Then in the Global settings of the Qubes manager set that Fedora ProxyVM as the default UpdateVM.

“sudo qubes-dom0-update” seems to work straightforward over Tor this way.

Anyone feeling awesome to document torified dom0 upgrades in the wiki?

Thanks for your comment. Any Qubes-Fedora VM (doesn’t need to be a ProxyVM) that is connected to Whonix-Gateway, and also selected to be the Update VM, will allow for torrified dom0 updates.

Since qubes-dom0-update is not a Whonix program, it is not torrified/socksified by default - meaning it uses Transparent Proxying for its traffic. The issue I was having was trying to figure out what and how to torrify in order to enable dom0 updates with Transparent Proxying Disabled. Unfortunately, I think my setup is too hacky to be documented. (torsocks port is fixed/not isolated). As Patrick said, it’s better to use uwt but too many things I don’t know how to do yet. (how to use git? is uwt compatible with fedora?)

I’ve been using a standalone VM but now I want to add additional Gateways with differing firewall configurations. So changing the TemplateVM won’t help. Also, it seems sub-optimal to abandon the security of a non-persistent root filesystem. So don’t want multiple standalone VMs.

I can think of 2 options:
On Gateway template:

  1. Add to rc.local:
    cp /rw/config/50_user /etc/whonix_firewall.d/ /usr/bin/whonix_firewall
    then
    cp /etc/whonix_firewall.d/50_user /rw/config/

  2. Edit /usr/bin/whonix_firewall:
    change
    for i in /etc/whonix_firewall.d/*; do
    to
    for i in /rw/usrlocal/etc/whonix_firewall.d/*; do
    then
    mv /etc/whonix_firewall.d /rw/usrlocal/etc/

Option 2 seems more elegant. Will that work? Did I miss something?
Thanks!

No need to delete/move anything.

In /usr/bin/whonix_firewall.

for i in /etc/whonix_firewall.d/*.conf; do

for i in /etc/whonix_firewall.d/*.conf /rw/whonix_firewall.d/*.conf; do

sources first /etc/whonix_firewall.d first and then /rw/whonix_firewall.d/. Untested. We probably should do that for next version anyhow. What about the folder? Is there any convention for /rw yet? @marmarek Perhaps in /rw/config sub folder?


related to storing the firewall settings… In Qubes in future there will be a feature aiding this use case.

bind-directories functionality
https://phabricator.whonix.org/T414

https://github.com/marmarek/qubes-core-agent-linux/pull/58


torified dom0 upgrades are now documented here:

Aha! Thanks.

My clumsy attempt seemed to be working okay.
Your instructions work as well.
Tested multiple gateways, with TransPort on and off.

Obviously, moving 50_user results in breakage of Application Menu shortcut:
User Firewall Settings
Symlink will fix I guess…

sources first /etc/whonix_firewall.d first and then /rw/whonix_firewall.d/. Untested. We probably should do that for next version anyhow. What about the folder? Is there any convention for /rw yet? @marmarek Perhaps in /rw/config sub folder?

Yes, /rw/config/something.

Will it be possible to override something set in
/etc/whonix_firewall.d?

marmarek:

sources first /etc/whonix_firewall.d first and then /rw/whonix_firewall.d/. Untested. We probably should do that for next version anyhow. What about the folder? Is there any convention for /rw yet? @marmarek Perhaps in /rw/config sub folder?

Yes, /rw/config/something.

Will it be possible to override something set in
/etc/whonix_firewall.d?

That’s rather simple in bash.

So we make it /rw/config/whonix_firewall?

No /rw/config/whonix_firewall.d required / suggested?

So we make it /rw/config/whonix_firewall?

No /rw/config/whonix_firewall.d required / suggested?

I meant “something” = “whonix_firewall.d” :slight_smile:

Done.

https://github.com/Whonix/whonix-gw-firewall/commit/d6c1e0bc95257c81d8c2bcd3d0959b37e53211dd

https://github.com/Whonix/whonix-ws-firewall/commit/e8674d48c9445def572d4a67fbcfe4e3c785a301