@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 
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
2 Likes
Great! I’ve now removed the wiki from there. Let me know if you need anything else.
1 Like
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:
/10.137.0.36/0000 = action=accept dsthost=www.google.com
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
/etc/tinyproxy/filter:
^registry\.npmjs\.org$
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?
Update:
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
1 Like
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.?
Does anybody have a good recipe for a filtering SOCKS proxy?
E.g. Thunderbird has difficulties connecting over HTTPS Connect method to IMAP port 993 and only works with SOCKS proxies. I would like to limit domains to the ones based on email provider.
Hi! Thank you so much for this guide!
I did it for one qube and it works.
I did it again for another qube with another rules.
So in dom0, I edited the file /etc/qubes-rpc/policy/qubes.ConnectTCP+8888 by adding one line for the second qube (I adapt the name of proxy qube of course).
When I try to go to unauthorized URL in my-qube-2, I have a window showing:
Denied: qubes.ConnectTCP
Denied qubes.ConnectTCP+8888 from my-qube-2 to...
Is there a conflict between the two proxys as they use the same port?
Am I doing something wrong?
Thank you!
My bad! When we write the names of the qubes correctly, it works! Sorry 
1 Like
Hi @Rooftop - Many thanks for your guide and related posts. It explained some key concepts, as well as the actual mechanics, such that I could use it as a jumping off point 5+ yrs. later. Now, that’s a high quality post.
1 Like
Can someone please explain how this is better than compartmentalizing approach - using one (template)-dipsvmtemplate-dispvm for each (set of) url(s)? I am using single dedicated dispvm to access this forum and no other url in it. If someone shares a link here I want to visit, I am visiting it in a different dispvm?
For example, using such a set to access only ebanking portal and not daring to open any other url in such a dispvm? Wherever I log-in, no other url/site in that dispvm.
Also, won’t many sites get break because hosting on multiple domains and subdomains with different names?
And lastly, by accessing multiple urls in a single qube kinda defies basic Qubes logic “security through compartmentalization”?
Hi @corporateblush, I will share some thoughts on why I’m taking this approach. I use disposables, Mullvad Brower, several different VPN providers, and whonix. However, for some situations, I want more control over what is both entering and exiting the qube (e.g., banking). I don’t want telemetry, ads, analytics, trackers, 3rd party affiliates, etc., in terms of privacy, distractions, and load times. As soon as you sign-in, a site will know something about you, but I won’t make it easy for the rest of the hangers-on or allow unknown “phone homes”. In a regular disposable, a LOT of that stuff will load, even with ad-blockers, etc. Why? Because ad-block lists are a moving target: one site is blocked and another one appears to evade the block. Even Mullvad, which I love, isn’t perfect.
I am using tinyproxy with explicit allow permissions and default deny. And yes, you need to figure out what things are essential for a site to function, but the tinyproxy log is a HUGE help in this regard. Thus far, I’ve found it just not a lot of entries and a well-written extended regex can cover many of them, but it can take some time. So, I would not take this approach for every site. As noted earlier in this post, you can use both domains and ip addresses, which is a big help. If you setup appropriate qvm-firewall rules and other proxy-related rules in your qube(s), you can also prevent other non-browser-related data leakage.
If necessary, I chain tinyproxy with other qubes/services (e.g., VPNs, tailscale, etc.) for additional functionality. For different qubes, I have unique filter lists in tinyproxy, and you can also have more than one tinyproxy qube for compartmentalization (e.g., banking-tinyproxy and forum-tinyproxy). I’m using a minimal template to dynamically create my sys-tinyproxy-appvm, but you probably could make it fully disposable as well if you wanted.
Obviously, you need to balance complexity, your use case, security, etc., but it another example of how flexible the Qubes networking stack can be in enhancing security. Finally, although I am far from being an expert, I’ve also learned a lot in the process, enhanced my security/privacy, and improved my web browsing for selected sites. Hope you find something that works for you, which could also be staying with your current approach.