"Now You're Thinking with Qubes"

[fiftyfourthparallel]

The concept of ‘qubes’ (the VMs) is a game-changer to me, since it allows for modularity as though you have a bunch of computers inside your computer–except these computers can be created, destroyed, and recreated at will; and also be modified and connected to your heart’s desires (if you have the technical skills).

I’m still stuck in the paradigm of using qubes in the prescribed method (sys-VMs, disp-VMs, etc.) and am wondering if there are more creative people out there who have found other ways to make use of this flexibility and power of feeling “like a god”, as Micah Lee puts it.

 

tl;dr - Do you use your qubes in a non-standard way? If so, how?

 

Side note: I also think a good catchphrase for this thread is “Now You’re Thinking with Qubes”, which is a humble homage to (or shameless rip-off of) the “Thinking with Portals” slogan from the famous Portal game series. This catchphrase might also fit into a tutorial series for Qubes.

[deeplow]

I love this idea of “Now You’re Thinking with Qubes”. Looking forward to hearing what other creative uses of Qubes there are! Maybe we can then make a memorable picture out of them like that one!

I have played around a bit more but still with lots more stuff to try. I’ll share here some creative usages I’ve seen, some that I’ve tried and some I’ve only thought about.

Open Qube as Disposable

Not something I’ve done, but I got a hint from the docs on this:

[…] a DisposableVM could be created based on the AppVM (thereby making the AppVM a DisposableVM Template) so that the data can be analyzed by an untrusted program without jeopardizing the integrity of the original data.

“Qube in a Jar”

For working on investigations (where the process is always the same) one can have a salt formula to generate with saltstak an AppVM fresh for every new investigation and after it is done, safely back it up in cold, encrypted storage. (totally stole this idea from this presentation)

“Phoenix” Qubes

(aka. Stateless Qubes Configuration) In theory you could completely eliminate any state (persistence) from your Qubes setup and regenerate it all from a saltstack configuration you created (kind of what people already do with their dotfiles – not really, but similar enough). Then, if you ever lost your computer, you would only need to git clone your saltstack config and deploy it. See securedrop-workstation for inspiration

Split Qubes

Not really anything new but I find the Split-* configurations quite ingenious. So I think they belong here.

Some examples: Split GPG, Split SSH, Split Browser, Split dm-crypt

Testing Infrastucture (ansible molecule deploy)

When working on DevOps a lot of stuff is done in ansible and you can use qubes to automatically provision that testing infrastructure just like you would do with vagrant.
Take some inspiration from securedrop (in particular “Deploying SecureDrop staging instance on Qubes”).

The initial setup is quite painful, but after that all you have to do to test your infrastructure

molecule create -s qubes-staging
molecule converge -s qubes-staging
molecule test -s qubes-staging

And then see the magic happen – Various qubes being orchestratedly created, tested and finally destroyed.

Open in Disposable Qube / Convert to Trusted

Also widely incorporated into the Qubes ecosystem, but also worth mentioning as Qubes-foo:

• Open / Edit in DispVM
• Convert to Trusted PDF

Higly valuable for manipulating untrusted documents.

Tor Over VPN (vice-versa)

Not really that out of the box, but it’s something that is only easily doable in Qubes (after reading the security implications).

Even though you loose out on a bit of anonymity, this allows you to bypass a lot of webpages that block Tor and it even works for audio conversations over tor (through BigBlueButton, for example).

Pause All VMs for Secure Operation

(Haven’t seen this implemented yet – as far as I know)
We know that harware-based attacks like spectre or meltdown can read memory portions in other VMs.

But imagine for example that while opening you password manager on your vault qube it pauses all other VMs, then you enter the passphrase (it’s now in memory), copies the password to the qubes-clipboard, removes your master passphrase from memory and then resumes everything else. (stole this idea from here and

This needs some more thinking since there may be timing-sensitve operations running on other qubes, but I believe this could easily be implemented via a Qubes RPC to dom0.

Export Qube to USB (bootable)

I’ve never seen anyone mention this, but it would be pretty incredible if someone could make a Qube bootable outside of Qubes OS. One would export it to a USB stick, plug it into a computer and it would boot with whatever distro and programs you had on there.

Use-case: Sometimes a journalist needs to do some on the field investigative work and it may be too risky to take the qubes laptop. So what if we could send a qube to a usb and make it a regular bootable operating system?

This way the journalist could take just that USB to the field and when she is back she could just restore that new version onto its original qube (basically just copying the files back).

Bonus: Being able to easily create linux bootable USB already configured (with the state of the AppVM). Maybe some people would want to share this with non-qubes users, for them to have a fully setup environment.

[fiftyfourthparallel]

@deeplow

“Qube in a Jar”

‘Genie in a Bottle’ has a nice ring to it

@deeplow

“Phoenix” Qubes

Couldn’t this be replicated with a dom0 script that checks if a template is installed, installs if not, then uses qvm-create, qvm-prefs, qvm-service, qvm-features, qvm-run -u root [apt/dnf] install [package] -y, etc? (I like the idea of a phoenix Qubes, but have an irrational aversion of saltstack)

@deeplow

Split Browser

Now you’re thinking with Qubes!

@deeplow

Pause All VMs for Secure Operation

On a similar note, one thing I want to see is the ability to restart entire network stacks for extra sensitive work–if I want to restart my ‘topsecret’ and all qubes leading up to it on the network (e.g. sys-net, sys-vpn, sys-firewall), there should be a command that allows me to do so without resorting to qvm-shutdown --all.

@deeplow

Export Qube to USB (bootable)

This is a neat idea that turns the Qubes OS machine into a mothership of sorts. However, from a security standpoint, the bootable loses all Xen-based protections and has to rely on potentially hostile hardware–wouldn’t this make the user incredibly vulnerable? This issue gets compounded when the user brings an infected qube back and loads it onto the mothership.

Why not use a modified Tails USB instead? I just feel like there are a lot of non-Qubes solution to this particular problem.

[deeplow]

@fiftyfourthparallel

‘Genie in a Bottle’ has a nice ring to it

It does, but I just don’t know how to qube-ify that phrase

@fiftyfourthparallel

@deeplow

“Phoenix” Qubes

Couldn’t this be replicated with a dom0 script that checks if a template is installed, installs if not, then uses qvm-create , qvm-prefs , qvm-service , qvm-features , qvm-run -u root [apt/dnf] install [package] -y , etc? (I like the idea of a phoenix Qubes, but have an irrational aversion of saltstack)

Well you could, but it wouldn’t be as maintainable. I think the qubes-salt integrations uses those internally.

The whole industry shifted from constantly broken shell scripts to yaml-like languages for describing configurations for a reason. I also used-to have an aversion to this sort of stuff, but once you get into it, you see how much more readable and maintainable it can be (note, I don’t know a lot about salt yet, mostly ansible. But it shouldn’t be too hard).

@fiftyfourthparallel

However, from a security standpoint, the bootable loses all Xen-based protections and has to rely on potentially hostile hardware–wouldn’t this make the user incredibly vulnerable?

Yeah, from the security standpoint it’s not great unless someone would come up with an idea of safely extracting back the information.

@fiftyfourthparallel

Why not use a modified Tails USB instead? I just feel like there are a lot of non-Qubes solution to this particular problem.

I had also thought about this, one would loose the customizations of the OS, but on the other hand get all the benefits of Tails.

[phl]

I think it’s debatable if the following should be considered non-standard uses but I think they nicely make use of the possibilities you have with Qubes and they actually feel quite cool when using them every day.

Using more than one sys-net

I work at a small company (~ 7 people) and we set up strict network segmentation over the last years. Using WiFi we can access the Internet, but nothing internally. Using Ethernet, we access our internal infrastructure but do not have access to the Internet, not even by a proxy or some other fancy security mechanisms. Instead, we all use Qubes laptops and have configured two sys-net VMs (with accompanying firewall VMs of course).

• sys-net-lan - for internal access only. Here you can connect VMs that work with internal files, access internal systems and the like.
• sys-net-wlan - here goes everything that requires an Internet uplink. eMail (restricted to the IP address of our mail provider), mostly disposable VMs for web research, but also stuff like Spotify (ever thought about using a DisposableVM to launch your pre-configured Spotify client in the morning?).

Printing from disposableVMs

When I first set up Qubes I created a dedicated printing qube in form of a persistent appVM. I would copy files over there, start a file browser in this Qube, navigate to the incoming folder, open and print a file, hopefully not forget about deleting it afterwards. But as humans are, something more urgent pops up before you can clean up after yourself and so over the time the qube filled up with old data. Turns out you can have this way easier and most of it is already stated in the official docs.

• Set up a dedicated template where you can install the potentially insecure 3rd party printing driver.
• Create a DisposableVM template out of this template.

Now, whenever I want to print something I right click on it and “Open in DisposableVM” it. Choose the printing DisposableVM from the drop down, wait for the print job to finish and just close the window. The dispVM halts and everything unrequired is vanished.

I think this approach could use a bit more fine tuning though. If you want to print multiple documents it is inefficient to open a separate VM for each of them. Something like a wrapper which creates a new dispVM if none is running and otherwise opens documents in the already existing print VM would be great.

[deeplow]

@phl

I think this approach could use a bit more fine tuning though. If you want to print multiple documents it is inefficient to open a separate VM for each of them. Something like a wrapper which creates a new dispVM if none is running and otherwise opens documents in the already existing print VM would be great.

Yes, I think this is is an idea on its own

Open in same Disposable Qube

This would have security implications, but a wrapper that would reuse dispVMs if they are already open would make it much quicker to do stuff (possibly leading to an increased adoption of disposable Qubes)

[GWeck]

Another option would be a separate minimal Qubes installation on the USB stick, containing only the required template(s) and possibly, but not neseaarily, sys-net and sys-firewall. You could then move the externally needed AppVM by backing it up and restoring it to the USB-stick Qubes. Then you would have all the protection features of Qubes, but the stick would only contain the data of this one AppVM.

Backing up and restoring just this one AppVM should be quite easy and quick, and could later on be used to move the AppVM back to its original location. This might be even easier if there were a function to import an AppVM from one Qubes installation into another one - but It have no idea if this could be done in a secure way, without compromising the exporting, the importing Qubes installation or even both.

[deeplow]

I think this idea is even better

[Cappire]

@deeplow

Pause All VMs for Secure Operation

(Haven’t seen this implemented yet – as far as I know)
We know that harware-based attacks like spectre or meltdown can read memory portions in other VMs.

But imagine for example that while opening you password manager on your vault qube it pauses all other VMs, then you enter the passphrase (it’s now in memory), copies the password to the qubes-clipboard, removes your master passphrase from memory and then resumes everything else. (stole this idea from here and

This needs some more thinking since there may be timing-sensitve operations running on other qubes, but I believe this could easily be implemented via a Qubes RPC to dom0.

Very cool idea.

Not exactly the same, but I think Xen 4.13 was to introduce an experimental feature to bring back hyperthreading by making it VM-aware, i.e. Xen won’t schedule processes of two different VMs on the same core at the same time.

The original spectre and meltdown only applied to processes sharing the same core (hyperthreaded), not different cores on the same CPU, right? Has a variant been developed that can steal data from a separate core? (I’ve lost track at this point.) Or did you mean this as more of a future-proof type of mitigation?

[fiftyfourthparallel]

@GWeck

Another option would be a separate minimal Qubes installation on the USB stick, containing only the required template(s) and possibly, but not neseaarily, sys-net and sys-firewall.

I think I see what you’re saying–basically instead of a mothership-lifeboat style division (installation to VM), it would be a big cell, small cell approach (full installation to minimal installation), where VMs are exchanged between installations.

I wouldn’t consider myself technical, but isn’t the current Qubes installation (Xen and dom0, without any VMs) considered minimal already? This would mean that any further minimalization of the entire setup would come from the VMs–like switching to mirage-like unikernels for different sys functions.

If we’ve reached the point where we have dedicated unikernels for sys-net, sys-usb, and other functions (which I would very much like to see), shouldn’t these become the default across all Qubes installations anyways as they’re much more secure (absolutely minimal attack surface) and resource-efficient than full-blown VMs? In other words, shouldn’t all installations of Qubes be ‘minimal’, and the proposal simply be for a Qubes that runs off USB and has the ability to swap VMs, which could already be done via backups?

Sorry for sounding terse and interrogative–just wanted to exercise my noggin and ask questions.

[fiftyfourthparallel]

@phl

Using more than one sys-net

I never realized it, but it should be possible to have one sys-net for every interface running concurrently right now–anything goes as long as they don’t share a PCI device. This means you can add a ton of network interfaces via USB and PCI and have your Qubes act as a sort of secure hub (no idea how this would be used, but it sounds versatile).

[Jarrah]

I never realized it, but it should be possible to have one sys-net for every interface running concurrently right now–anything goes as long as they don’t share a PCI device. This means you can add a ton of network interfaces via USB and PCI and have your Qubes act as a sort of secure hub (no idea how this would be used, but it sounds versatile).

To answer the “how it would be used” part, I have three NICs on my Qubes
machine.

The first provides internet access, which is then filtered through
sys-firewall to provide mail, web browsing, etc.

The second provides a very restricted admin interface to the network it
manages. This is used for SSH to these machines, but cannot send
mail/browse the web.

The third is passed directly to the relevant VM for things which require
port forwarding or less filtering than available on the first.

This way, an attacker were to gain access to my mail client, or a
dispVM, not only would they be limited to the VM and it’s firewall
rules, they would also be limited by the network segment that the VM
lives in.

[phl]

Well, another idea how to use it is right there in my previous posting ;). One netVM for Internet access, one for local network only.
I am sure if I had some more NICs I could make use of them. For example we have two Internet uplinks (static/dynamic IP). I could provide Internet access to regular VMs using the dynamic uplink. Others, e.g., for VPN connections to customers or for administration of remote servers, could then use the other uplink.

[GWeck]

Here I am not thinking of a hardened or stripped down Qubes, but just a mobile system containing only the VM(s) needed when travelling. If the other VMs stay at home, they are secure from snooping by customs or whoever. This mobile Qubes could be just a standard installation without any addidional hardening.

With respect to hardening, the first step might just be to use the Fedora-minimal template for sys-net and sys-firewall. Using a more secure kernel for these VMs would surely help, but I see this as a later step. Currently, my main concern is the security of the Xen hypervisor. So far, about two thirds of the Qubes Security Bulletins are caused by flaws in Xen, many of which are critical for Qubes security. So I would prefer to replace Xen with a secure, possibly certified microkernel. The current implementation of Qubes, which uses a hypervisor abstraction layer, should make this feasible without too much effort.

For this reson, I proposed some time ago to build a Qubes implementation based on the certified L4 kernel developed by the university of Dresden and used to process NATO classified data. A first rough estimate showed that this should be possible, but so far, I found nobody able or willing to perform this task - and, of course, someone to pay for the development. But I am still dreaming …

[https://github.com/QubesOS/qubes-issues/issues/3894]

[unman]

The only current option would be to use a unikernel for sys-firewall.
Now that the mirage fw works with the Qubes firewall system this is
a viable option. Package is minimal but will add some to the
configuration.

The main issue with the current installer is that it provides
templates:

whonix-gw 371M
whonix-ws 621M
Debian 858M
Fedora 1.4G

It’s these that push the size. dom0 is already pretty stripped.
One option is to remove the Debian template - I’m a Debian lover so this
isn’t an option.
An alternative is to use a TorVM on first boot, and save on the 1G used by Whonix.
Users who want the Whonix system can always install it later.

I used to have an installer that did exactly this, and used the extra
space to give a full Debian system as default template. If any one is
seriously interested I could dust it off and see how it works now.
I think we could probably push this even smaller with a minimal template
with a few added packages for networking etc: what would be the ideal
target size?
(I think I’ve already made it clear that I don’t think the size is really
an issue these days, and we’ll never get Qubes on a CD - remember
those?.)

[unman]

Most laptops come with network and WiFi I think. You can get a
wired-to-WiFi or wired-to-wwan connector, or add more wlan or wwan
connectors easily enough: either on existing hw interfaces or using usb.
Naturally you would want to use different USB controllers if possible.

I strongly recommend splitting traffic - I’ve posted on this before.

[panati]

Best option can be dom0+ minimal templates+ Whonix full version. But minimal with networking packages included cannot be a good option. Networking requirements if can be provided out of dom0 and minimal templates will be best (Why I think that is because any user may want some appvm which does not contain any networking code/packages/anything possible at all). But It’s not possible without funding I think as @adw mentioned.

[unman]

I dont quite understand what you say.
What little evidence there is suggests that Whonix users account for
less than 10% of Qubes users (if updates are any guide), so I cant agree
with you.
The best option is a fully workable Qubes system with the option of
using Tor at install, and the option on configuration (or after) of
downloading, installing, and using Whonix.

Funding would be nice, but is not essential - if there is really any
call for this, and I’ve already said that I doubt there is. Convince us
it’s necessary and it will be built.

[wobo]

So you are saying that only 10% users are using Whonix. I may disagree here. I use whonix but don’t use it for updates as it’s slow. Not everyone on this earth has 300 Mbps connection.
But I will say that what panati suggested cannot be default option because it makes new users helpless as customizing minimal templates can be confusing for new users. But it will certainly help many advanced users (but then again it means maintaining two iso may be or may not be feasible). I even highly appreciate if that can happen someday.

[wobo]

With respect to hardening, the first step might just be to use the Fedora-minimal template for sys-net and sys-firewall.
I would like to add fedora/ debian minimal templates to create disposable sys-net, sys-firewall and sys-usb.