One of the oldest Qubes OS “VM / Qube” examples is the “trusted browser Qube”. Its where you have all the websites you trust.
I have a list of say 20 of those websites. Banking, hosting providers. Stuff like that.
Since using Qubes-Snitch (a firewall thingy thats in-dev rn that I build, which lets you selectively accept/reject DNS and connections as they happen), I’ve began to question my life choices with my “trusted browser qube”. Its one thing knowing that all websites talk to god knows whom as well as facebook, its another to see it and get popups for each connection attempt. It all feels so nonsensical. I have to allow 400 different CDNs just to do my stupid taxes, or JUST to log into the site where I do the taxes.
Then I might as well not restrict it. Every goon can just book that CDN, and now my firewall allows it.
My last resort would be to just forget the trusted browser and use dispvm browser for everything - ideally each website individually. Then I might as well not use a firewall there as well. Maybe tcp/443 only and thats it. And DNS ofc, as in “has DNS”, not “has selective DNS” like in Qubes-Snitch.
How do you guys handle this? Do you use qvm-firewall for your trusted browser stuff? Or did you just give up on it?
Torbrowser for everything? If I want banking / taxes I have to allow a THOUSAND CDNs, which means I allow everything that CDN does, including all of its other customers.
Its a bit frustrating rn to have that much power / insight (Qubes-Snitch) lol.
Maybe create a appvm without internet access, start the browser, create all the bookmarks and then create DispVMs from it? I don’t need the browser to store the passwords…
Those 20 websites should have their own qubes. All other browsing in dispvms. Rarely used sites, can be used from dedicated dispvm instances too.
Qubes-os makes this easy. Its almost like appvms is a bookmarks for those sites.
You don’t know what vulns and trackers these sites will have tomorrow. Best to contain the blast radius if anything does happen. You can pick the best template, browser, netvm with tor or a vpn if you want, and extensions for each one.
I’ve been trying to set up a qube for all my financial stuff online recently and firewall it off. I already had my suspicions, but I’m in a similar boat as you. It is indeed eye-opening to find out that your tax company has 400 of its closest friends helping them as well! I ended up just giving up. The internet is broken. I hope to find a better way of doing things soon, online or off.
But @xahare I kinda thinkg similarly… Have an app Qube with apt install chromium without internet (but apt proxy), add the bookmarks manually there, and then use it as a template for DispVMs. Each time I want to visit a website I spawn a Disp and use it. My box is strong enough to support such nonsense, and I use sth that lets Qube’s go to sleep (qvm-pause) automatically when they are not focused in i3wm. So this might be what I’m aiming at.
Only issue is I still want that firewall… You usually can reject the nonsense and the sites still work half way well…
Qubes-Snitch, the firewall thingy I’m working on rn, does support rule-templates for dispvm’s based on a specific app-vm, but it does not support rules based on launchers which start the dispvm… MEH there is always something LOL
The internet is broken. I hope to find a better way of doing things soon, online or off.
Hm there is always a way…
I could setup Qubes-Snitch to work with launchers, but then this would be very kuhbs (the enduser automation system I am building rn for Qubes, think “appstore” for endusers → “install thunderbird”, "install signal’, “install browser” and alike) integrated…
So long story short… MEH.
I think the AppVM with bookmarks for DispVMs is the right answer here, instead of building firewall rules to support all my 20 “trusted” xD websites…
Maybe something like:
kuhbs password store (doesnt exist yet)
understands this (the user + password + target) is a website
spwans a dispvm and opens the website there
has firewall (Qubes-Snitch) rules for this specific website
loads them for this dispvm
So long story short launcher based…
I think this might be the solution for “firewalled trusted browsing”.
Endusers will have to download a LOT of ram for kuhbs lol.
Wdyt? Sound solution? This way you can create firewall rules for each site individually, and use the site in a dispvm with good automation…
I would treat the boundary as identity/account risk, not as a perfect network allowlist. A banking/tax qube still helps because cookies, downloaded files, browser profile state and login sessions are not mixed with random browsing, even if the site pulls half the internet through CDNs.
For the firewall part, I would keep only coarse rules there: target site domains, DNS, 443, maybe block obviously unrelated categories if your tool makes that easy. Trying to approve every CDN hostname can become false confidence, because the trust boundary moved to the CDN account/config anyway. For high-value sites, a dedicated AppVM or named DispVM per identity group sounds more useful than one big trusted-browser bucket.
K here is the plan, can’t build this today because I have work to do that makes actual sense, but I think its pretty sound:
Minimal / KISS design:
a) KUHBS launcher (rofi) supports prompt arg
Example launcher:
- id: browser-url
- command: /usr/bin/chromium {arg}
- dispvm: True
- arg_prompt: True
- arg_slug: domain
Rofi asks URL/domain, e.g. banking.com.
b) KUHBS launches DispVM with that arg
Runtime:
- input: banking.com
- slug: browser-banking-com
- qvm-run starts disposable from app-browse
- command becomes:
/usr/bin/chromium --open https://banking.com (pseudo code)
c) Snitch needs launcher identity mapping
Not “guess from disp1234”.
KUHBS should tell Snitch:
disp1234 -> browser-banking-com
Then Snitch uses:
/rw/usrlocal/qubes-snitch/rules/browser-banking-com.yml
not disp1234.yml.
New allow/reject decisions are saved into browser-banking-com.yml, so next time same domain gets same policy.
So the clean patch surfaces are:
1. KUHBS launcher arg prompt
2. KUHBS launcher arg templating into command
3. KUHBS writes runtime identity:
disp1234 browser-banking-com
4. Qubes-Snitch source resolver checks that mapping before falling back to normal DispVM policy
That gives editable, persistent, per-site rules without making numbered DispVM rules persistent.
Only thing missing here is a funky password manager, but thats for yet another day.
Speaking of which, what password managers do you use in Qubes? I was always thinking of something that puts the user + password into copy paste buffer automatically, with maybe like a 3 second delay for user then password or so.
Hm yeah disagree here. It may be fucked up, but this is possible-ish.
Yeah that is an issue, but files you can copy out, cookies can go fly a kite. I can just login again and do the extra security verification thingy I think.
I’ve been thinking about this too, but I just don’t like persistence in general. I’m not a fan of AppVMs where its not absolutely required, and I can login to my bank in a fresh browser.
This solution can be used where it works, and for all others the user can still create a regular banking-browser kuhb (or Qube).
As I am test-using Qubes-Snitch myself I keep experiencing that problem… I open a site I visited before but it always gives me new IPs that I have to approve, which is bs.
My idea here is to add sth like [a/A/r], where A creates a rule for the CDNs A DNS record, which is resolved upon starting Qubes-Snitch, and resolves to multiple IPs. This way Qubes-Snitch doesnt ask “want to accept traffic to asdf.cdn .com, with IP 1.2.3.4” (or it does ask that), but I can answer “I want a rule that creates whatever is behind DNS A asdf.cdn .com during Qubes-Snitch start (or restart)”.
This should work I think, and make using Qubes-Snitch a lot less painful in the long run.
Once there was a day when I didn’t have funky ideas of more things I could automate in Qubes. It was a tuesday x)
yeah i used to do the same, but that’s just to annoying. You can’t expect endusers, or at least entry-level-techy-linux-users to do that. It’s to complicated, and even if you know how to do it, it breaks all the time and costs to much time. It’s not the solution.
I’m adding “build accept rules for all IPs that foobar.cdn .com resolves to” right now. That should be the solution, I think. Lets see how it holds up over a week of testing…
The only issue here is that my VPN auto swtiches configs every now and then… Meaning stupid GEOIP will resolve new IPs then. What is nice for latency is annoying for firewalls xD Will have to restart my Qubes-Snitch each time I restart my wireguard (it auto-selects a random .conf file in /etc/wireguard).
Maybe a small script for it…
I usually partitioning my digital life according to:
if it’s personal stuff or work related?
How much I trust that ‘thing’ that I want to do inside?
do I need to ‘remember’ things inside or not? (if not, then it’s automatically running in a dispVM)
and what is the real purpose
Based on those questions and it’s answers I ended up something like this:
separate WiFi and Etherent - instead of the single default sys-net.
one sys-firewall - but I barely using it**
multiple VPN qubes, depending on where I need to be ‘appearing’ from.
one (or more) VPN for my work relates stuff,
work related VMs,
non-networked vault VM for my KeeassXC
one AppVM for my government related stuff (those things that I must trust, but still not mixing them with others)
some personal AppvMs for gaming, development, photography, and ‘general’ usage.
multiple instances of disposable VMs - and that’s what I use (and recycle) most of the time!
And connecting them according to my actual needs, for example:
Work AppVM(s) → Work VPN → WiFi
dispVM → (one of my) VPN VM → WiFI
Personal → Home VPN → WiFi
And sometimes just as simple as:
dispVM → WiFi
Personal → WiFi
Development, Home IoT → Ethernet
So I believe the VM level separation and the network connection ‘structure’ are booth very important. And ofc you as the user should be able to decide what you actually do from which VM.
So much work for what? Bookmarks? I just have mousepad in vault and copy paste links into disposables. The disposibles themselves are built for if it is banking, accounts, browsing etc… Seems easier than split-browser.
I got it wrong there - visit to the bank was to enroll the phone as 2FA. 3rd factor is in paper format and comes in the post, but must be activated by one of the other two, IIRC.
Changing the browser can reduce default background noise, but it will not remove the third-party endpoints the site itself requires. I’d test with a plain Firefox/Chromium plus uBlock Origin first, because LibreWolf or Mullvad Browser can add fingerprinting and login quirks on banking/tax portals. For the Qubes boundary, I’d separate it more simply: persistent AppVM only where 2FA/browser registration needs state, named disposable for low-state sites, and firewall rules coarse enough that you can actually maintain them.
The dispvm template with bookmarks might have a trackable fingerprint. Either this or a future version.
It may be possible for an attacker to see your bookmarks. Again, this or a future version.
If it matters, ublock origin wont work with chromium for long. To get around that, I use firefox with UO, but use standard template as the dispvm template, so its always the first time it runs. FF doesn’t have great defaults, esp pinging their server every time your running it for the “first time”. A few of those and anyone familiar will at least know your running a virtualized os with disposable vms. To solve this, the template has a policies file telling it not to ping the mothership, and to turn off the tracking and all their partners nonsense so all you get is a blank start page. Fedora overrides the policies file, so I use debian for these dvm templates.
Theres also arkenfox, which looks like a more elaborate config. Haven’t tried it, but its probably worth looking at.
Now you can use keepassxc from the vault as your bookmarks. Entries can have url, username, passphrase, and totp. Just copy paste as needed. No launcher required. If you use the whonix dvm, remember to start that with its terminal app so torbrowser can check and update.
If you do want one, you could script a “browser” that opens a dispvm from there. Then keepassxc is your launcher. qvm-open-in-dvm takes urls. qvm-run-vms has a flag for dispvms so you could use that if you have multple dvm templates.
For some sites, its better or just more convenient to keep a running session. For those, I make that dedicated appvm.
Well when I login to my bank, the bank will know its me Hard to get around that
Although the plan posted above now does (pseudocode) browser --open banking.com, so it doesn’t need bookmarks anymore.
This thread is mainly about “how to firewall the 20 sites I visit regularly, where I login and which are banking and alike”. Or the qubes forum, but finding out who I am isn’t hard, which I don’t mind in this case.
Websites are distrusted infrastructure, so are heavy browsers. Network filters (qvm-firewall) and HTTP request filtering (uBO) help. Restrict to the essential minimum.
Torbrowser for everything?
Only for anonymous/pseudonymous browsing. It makes zero sense to e.g. do your banking in TB.
I think you answered that in part c of your pseudo code. For password management, keepassxc-cli can get the data. But it doesn’t have a command for running the browser.
Gives new meaning to the term Extreme Isolationist
Hard to get around that 