Restricting a qube to selected websites

@deeplow, I can’t edit my original post any more. What’s the best way to put out an updated guide? Thanks.

Can you turn your post into a wiki?

That’s what I should do. I better head off and read up on contributing to the documention now :slight_smile:

1 Like

The post is now a wiki @Rooftop. You should be able to edit (and so can anyone else, so let me known when you’re done with the editing).

Yes, once finalized, it may be worth moving into the documentation (or the community one).

Thanks @deeplow. I have now updated the first post to include @icequbes1 suggestions and even a few screenshots :slight_smile:


Great! I’ve now removed the wiki from there. Let me know if you need anything else.

does anyone know how sys-firewall gets it’s configuration information from the “firewall rules” tab of the qubes-GUI?

If so, could this be extended to utilize that instead of /etc/tinyproxy/filter?

The qubes-firewall service gets its config via the qubesdb - this is how dom0 passes various info to the qube.

Run qubesdb-multiread /qubes-firewall in sys-firewall and you’ll see the firewall rules that are specified for active downstream qubes.

Going up a level, dom0 allows configuration via qvm-firewall.

And if you want to take it even further, the firewall config is persistently stored at /var/lib/qubes/appvms/VM-NAME/firewall.xml.

So in theory you can hijack qvm-firewall config and hack on the qubes-firewall service in the firewallVM to use the config however you’d like. You could maybe have a firewall rule hostname prefixed with something that qubes-firewall has been hacked to ignore as a typical firewall rule and pipe the value to tinyproxy config.

The above assumes the downstream qube has your hacked firewallVM as its NetVM. What is discussed earlier in this thread takes a target qube, denies it network acccess, and uses Qubes RPC to proxy traffic to another qube running tinyproxy. The target qube must have been explicitly configured to use the HTTP proxy of the tinyproxy qube. It’s a different model so want to ensure it’s clear.

I found that qubesdb-multiread /qubes-firewall produces things like:

/ = action=accept

so putting in cron something like:

qubesdb-multiread /qubes-firewall | grep dsthost | sed “s/^.*dsthost=\(.*\)$/^\1$/” > /etc/tinyproxy/filter; service tinyproxy reload

(note, those should be normal quotes, not the special quote characters that the editor is changing them to)

…, that would allow people to type the hostnames they want to whitelist into the qubes firewall settings instead of manually typing it into the config file?

(Note to anyone reading: if it worked, then all VMs using the proxy would be able to visit any hosts specified in the firewall settings of any other VM using the proxy (as well as their own firewall settings. I.E. it does not take which VM is which into account. (This is consistent with the instructions above))

(Also note, I do not have tinyproxy set up so I’m doing my proposal blind)

This is awesome! However I experienced similar problems with the tinyproxy “hanging”.

E.g. when installing (arbitrary) npm packages of bigger size and multiple dependencies:

npm ci



Log does not show anything obvious:

tail -f /var/log/tinyproxy/tinyproxy.log

I needed to restart the proxy qube two times to let npm ci finish finally.

Does anybody experience similar issue and has a workaround?

On first glance, following config entries in /etc/tinyproxy/tinyproxy.conf have solved issues:

#MaxClients 100
MaxClients 1
#MinSpareServers 5
#MaxSpareServers 20
MinSpareServers 1
MaxSpareServers 1
#StartServers 10
StartServers 1

Would my-proxy work with a Debian template? Is there a reason for indicating Fedora?

If a Debian minimal template were used (or Fedora minimal), what would be required to be added to the minimal template? I assume:

  • qubes-core-agent-networking
  • tinyproxy

Anything else?

What would the recommended settings be for Memory/CPU on my-proxy?

  • Initial memory?
  • Max memory?
  • VCPUs no.?