"Now You're Thinking with Qubes"

Network interfaces are always assumed to be compromised, yes?

So is the benefit of this approach that it gives you the flexibility to chose the device, or is there a security benefit of isolating two network devices from each other?

Perhaps hypothetically if you had an external WiFi adapter that you used to connect to public wifi’s for sensitive journalistic uploads, and an ETH or onboard WiFi for home network, would having them separate prevent some kind of leak or some kind of log of useful data that your more trusted network device gained from its home connection that could be accessed or exported by your riskier external adapter device? This may be completely ridiculous just trying to understand any security gains from isolation here.

@Brainhack Can you tell me what the added security is of the setup you mentioned?


Did you have a look at my original post that @fiftyfourthparallel is refering to?

Maybe this can give you more ideas when such a separation might be useful.
What I wrote there is basically what we still use today.
Of course, with the whole pandemic situation our work has shifted to more home office in the last years, and this setup can handle such a situation perfectly fine.
When I am not in the office, I can connect “sys-firewall-lan” to a VPN Qube which then goes out through either sys-net-lan or sys-net-wlan, depending on whether or not I have an Ethernet cable connected. I am currently thinking about renaming the firewall VMs to “sys-firewall-trusted” and “sys-firewall-untrusted” to better reflect their versatility.

I think the most benefit of this setup can be drawn if you have a physical network setup that supports your segmentation approach, such as in our situation (see my post from 2020).

1 Like

I always recommend separating network devices to distinct qubes for this
There is some cost in convenience: if you are travelling and want to use
WiFi you may have to change a qube’s netvm if you want to be online.
This is no bad thing since it may make you think whether you really
need that qube to be online at all in this case.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

Or you could use an intermediate routing-only VM between the appVMs and the netVMs.
This would allow to “swap” connections without restarting any VM and changing no VM setting in the manager.

To add to what everyone else is saying:

Don’t assume what is known is all that is out there; it’s a good way to get nasty surprises (hello Log4Shell). Keep the unknown unknowns in mind–especially when it comes to infosec. Risk management is the real name of the game.


Awesome :slight_smile:
Maybe this forum can be upgraded into the same mindset with disposable forum accounts!
Now we first have to create an email address, create a new forum account, wait for an email to be sent… before we can write a post. Very cumbersome.
It would be handier if we would have a choice: log into our non-disposable forum account, or log in as guest with a randomly assigned username, which becomes inactive after use. If that isn’t thinking with Qubes :smiley:

Other idea’s that would be handy :

adjustable titles for disposable qubes.
Now, if you have a dozen or more disposable qubes in use… things get consing… what disposable is run from what template and connected to what network? Now we have to open qubes manager and look at the numbers, for example:

  • disp4399 anon-whonix-dvm via sys-whonix
  • disp5028 whonix-ws-16-dvm via sys-whonix
  • disp544 debian-11-dvm via VPN1
  • disp6844 debian-11-dvm via VPN2

Maybe the titles of disposables can be changed in something like [disp# $templ $exit-node] $webpage-title Tor Browser
with $templ maybe something like:
$templ=d11 # for debian-11-dvm
$templ=d11min # for debian-11-minimal-dvm
$templ=fXX # for fedora-XX-dvm
$templ=anon # for anon-whonix-dvm
$templ=who # for whonix-ws-16-dvm
and $exit-node maybe a country-code, and ‘no-net’ for isolated disposables?

Extra colors
and maybe add extra colors… => 50 shades of red?
Now all disposables are the same kind of red… so are the other untrusted qubes

Being able to reboot a proxy-vm
now if we want to reboot a qube, for example a disposable [sys-VPN], we first have to disconnect everything that is connected to it before we are able to shut it down and/or reboot. I can see the point of this with a shutdown… but not so much with a reboot.
Like: sys-whonix hangs? Though luck as we have to change the network settings of each and every disposable qube we wanna keep using, reboot sys-whonix, then reconnect all those disposables again.

same as last suggestion but instead of rebooting the proxy-vm, first boot a new version of the (of course disposable) proxy-vm and replace the old proxy-vm with no network down time.

Yes, I love disposables! Best inventions ever!
I actually practice the same technique in my non-computer life: while working on a project, I’m 100% focused on the task. But as soon as the project is finished, it’s deleted from memory!
“Thinking with Qubes” = “living in the moment”
The only time is “now”, the only place is “here”. Time and locations are merely illusions…
The hubby/wife hates it though… “hey hon, how was your day?” => “hmmm… I don’t remember, project must have been finished…”

Awesome! You have my vote! (although disposable forum accounts don’t get to vote :p)


One solution is to create ‘fixed’ disposable qubes (or ‘fDisp’) for specific purposes. For example, a disp qube for opening PDFs might be called ‘disp-pdf’.

  1. Create a disposable VM based on the desired template (make sure ‘disposable template’ is checked in the GUI, or use the qvm-prefs command)
  2. Set that as the global default disposable template via the Global Settings menu, accessible via Qubes Manager
  3. In a dom0 terminal, type qvm-create -C DispVM -l red disp-pdf

disp-pdf is now accessible from the Qubes Manager and can be configured just like any regular qube. This is how disposable sys-qubes are usually set up.

Make sure the newly created fDisp is properly configured, then use that to open PDFs. Keep in mind that only one instance of this fDisp can be active AFAIK, but it shouldn’t be an issue with diligent window-closing (I highly recommend github.com/tasket/qubes-scripts halt-vm-by-window). If you need two open at the same time, repeat steps 2 and 3 but with disp-pdf2 instead.

Since you seem to have a fetish for disposables, much like I do, you too can indulge your wildest disposable fantasies by making using this simple three-step method.

This is pretty much how your computer should feel like when all is said and done:


Anyone have any creative applications for disposables?


That reminds me… I also love the “Shut down when idle for more than 15 minutes” checkbox for disposable proxyVM’s… but… how do I set that to 1 minute instead of 15? Or even 15 seconds (since proxyVM’s can’t be shut down if there’s still something connected to it (unless they add that feature)).

Not only for computers! One can increase their happiness level tremendously by de-cluttering the mind. Like for example: Always be your happy self! That way your friends will love you, stranger will want to hang out with you, and your enemies will be pissed off as they don’t understand why you are so happy and friendly after they kicked you in the guts last time.

I, for example, live a nomadic lifestyle. Some months I talk with 100+ random ppl daily, other periods I don’t see a soul for months. It’s always awkward when a stranger suddenly starts talking to you like “Hey [name], a couple months ago we had a deep philosophical conversation about X, and I was wondering how you would apply that to situation Y”, all while I’m trying to remember “have I met this stranger before?” :-p
Of course, when someone asks a favor, I quickly check the [Vault] in my brain, and

if [“no data” (as nothing worthy of holding a grudge over happened)]; then
I help that stranger as if they are my best friend… as - in that moment - they are :slight_smile:

Anyway… getting distracted again…
To stay in your theme: disposable forum accounts are like:
Collect call from-“I’m not giving my name to a machine!”

1 Like

Ninty two qubes, regularly using around 92% of them and still counting.

“Now I’m Thinking with Qubes”?

1 Like

I’m going to assume you are the person I replied to (@wdfqcnc).

How much work is it to make a disposable account for every message? Is it worth it?

try it for yourself
open a disposable whonix-ws
type in forum.qubes-os.org
press [ctrl]+tab
type in guerrilla mail
From now on, work parallel, while you browse the forum, click on the first link in duckduckgo, which is https://www.guerrillamail.com/
guerrillamail automagically gives a random account, in this case xpmjoveh @sharklasers.com
then create new account on this forum
copy/paste email
as username and name I just select the text before the @ and press middle-mouse-button twice
as password fill in whatever
then wait for an email to arrive. But you don’t have to wait as in the meantime you can do other stuff, like open a mousepad and start writing your forum-post :wink:
When email arrives, click a link, and another link.

Is this cumbersome? Sure. But if you use the same account with a decent password, like one generated by < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};echo; for example, then I’m not even going to try to remember that… so in that case I have to boot [vault] to open my logins/passwords file, then [shift]copy/[shift]paste it, which is almost equall cumbersome…

Maybe there’s a better/automated way to manage passwords cross-qubes, but I haven’t looked into that yet :-/

Or use a simple, easy to remember password that is easily compromised… but then what is the point of having an account if it’s not secure? (or - God forbid - use the same password as you use on other websites)

dunno, that’s a personal question. To me it’s like second nature…, so to me it is.

I would encourage everyone to use the same method as that would increase both your and my anonymity :wink: :-p
The down side is of course that we can’t build up a reputation, but I’m not ruled by my ego, so that’s fine.
Also, anyone who knows the email address you used can easily change your post using “I forgot my password”. (Have fun changing this post :-p )

1 Like

I find this to be a very fast process, personally. I love Keepassxc in vault. Signing up for a new account with guerilla mail each time to post seems a lot less convenient. And then you have the issue of returning to threads etc.

And do you manually pause all qubes connected via via to sys-net, and then manually unpause them again after you’ve closed [Vault]?

Manually pausing all qubes just to “safely” copy/past a forum-account-password sounds way more inconvenient than simply making a new account :-p
Hehehe, of course out treat model is not as severe that we have to worry about that of course… but yeah… security or convenience… that’s what my windows-friends tell me too whenever I talk about Linux… they prefer the convenience of windows, lol, and then I didn’t even mention qubes :-p

Oh, this for sure! I’m 100% with you on this one :slight_smile:

I think Spectre/Meltdown attacks are a very advanced threat that I’m not even sure is in the wild.

So no, I definitely don’t. Not near that threat model.

All the passwords I protect in my vault I not too long ago had saved in browser cookies, so this is a sufficient step up in security :'D

And I find it faster than any system I’ve used before also.


I think this deserves to be here:

1 Like

Above someone mentioned running two separate sets of network and firewall VMs, one to mind ethernet and one to mind wifi. As it happens I did this on the very first day I had Qubes OS; because I didn’t know how to get the system to try to update over a machine NOT named sys-net; I simply made that the WiFi-only machine and created sys-net-ether and sys-firewall-ether. (Now I do know how to do that and so I’m now using sys-net-wifi and sys-firewall-wifi.)

OK, here are a couple of other things I’ve been doing:

Sort of like Phoenix Qubes: When I converted my laptop over to Qubes, I did the default install, then copied my salt files (lots and lots of them!) over. I was then able to set my laptop up much like my desktop, excluding some things that didn’t make sense. (The laptop doesn’t have ethernet capability, for instance, so anything ethernet based doesn’t get installed there.) After going back and forth a few times, I’ve got it to the point where I can copy the entire salt area over, then regenerate from scratch; one file generates two or three others that differ by hardware and the rest goes from there. Almost everything in that directory is read-only. (I have one bash script whose job it is to tell its caller whether a VM should be generated based on which hardware it’s running on.) Alas even Qubes can’t do anything about slower laptop processors and screens.

My email client. Yes, I’m old school, I download my emails into a client program (thunderbird) and HATE having to use webmail when away from my home computer; any Email I send will never, ever be able to go into the “sent” folder on my client; it’s online in what amounts to a “cloud.” But now with my laptop having template VMs identical to my desktop…I can simply back up my EMail client AppVM to a thumbdrive and restore it to the other platform. (As soon as it’s backed up, it gets renamed to MyEmailQube-Backup so I don’t accidentally use it while the “other” machine has the “main” copy.) It takes about fifteen minutes to transfer from one platform to the other, unfortunately, but I can now take my email client with me!

1 Like

So if I’m getting it right, the advantage of using Phoenix or Salt-regen Qubes is portability and interoperability? Are there other advantages over disposables in terms of security?

I’ve been looking to learn Salt, since it seems to be the key to creative Qubes use, and you might just give me my reason.

Before I was using salt, I was using scripts to set up virtual machines; one for each.

I’m still using scripts, only now they invoke salt. Salt normally operates through “tls” (top level something-or-other) files. One of the things you’ll end up learning is that every invocation has a “target” and it may not be intuitive. To create a VM the target is dom0 (since it actually performs the task); but when you want to install software, muck about with configuration or “dot” files, etc. your target will be the VM itself. Salt will start that VM and execute commands on it. (My scripts could do something similar, but it took some hoop-jumping…I had to run a script on dom0 that copied my other script onto the VM, then dom0 had to do a qvm-run on the machine to tell it to execute the install script.)

So now as I set up minimal templates, it goes something like this: Create Template A (target dom0). Configure Template A (target: template A). Then clone Template B from template A (target dom0), because B is A plus a couple of apps. Configure Template B (target Template B).

The problem is I couldn’t for the life of me get Salt not to immediately clone B from A after creating A (but before A was configured). There was no way to tell dom0 to kindly wait for Template A to finish doing its thing before moving on, not within one tls or sls file anway. It could be done by breaking dom0s task up into multiple sls files, but then…I needed a bash script to manage that.

So I generally run salt from a bash script now. Even so it still has its advantages. It’s smart enough not to install things that are already installed (my scripts were not), and also smart enough to realize that something that is installed now can be updated. (It also integrates well with the Qubes updating scheme; I can get the updater to run my salt states.) So to update a template I re-run the configuration salt formula (I sometimes also run the create one, but since the VM already exists it just resets prefs and features if they have been changed, or changes them if you changed your salt file). Since I was able (with a bit of convoluted variable setting) to get Template B’s configure file to include Template A’s configure file, it will update everything, including the stuff cloned over from A. In fact, I can do this even if A has been deleted.

I was able to copy all of the salt stuff (and configuration stuff that salt installs) to my laptop, and run it there (and fix incompatibilities as they arose). But you could do all that with scripts.

One thing that just flatly doesn’t work with salt is updating the menus. The gui way to do this is to go to the applications tab in the settings window and refresh. (But note that if you do this in a named disposable it will not reasses what’s in the templateVM, only what’s in the disposabel template.) On the command line, qvm-sync-appmenus is the command that should “fix” menus and it works…from the command line. It must be run in dom0. You have to start the VM, then run qvm-sync-appmenus, then shutdown the VM. Setting up a dom0-target salt file to do these three steps simply doesn’t work. The states execute but there’s no effect; the things qvm-sync-appmenus are supposed to affect are not affected. This is another reason I’m still using bash scripts; once I have created and configured my VM, i start the VM, run qvm-syn-appmenus, then shut it down again in the script.

I too replaced extensive scripting with Salt.
I work through the issues that @SteveC mentions by using ordering and
requires in the salt states, and by building hierarchies of states.
It is a good thing to have multiple state files, since it accords with
the general salt approach of modularity and clarity

I think we have discussed the question of updating menus in another
thread. I don’t find doing this any more unwieldy in Salt than using the
command line directly, although I should say that I don’t make much use of
the Menu myself and am only interested in this when configuring for

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

3 posts were split to a new topic: Salt state dependencies