App Sandboxing

What is the best way to apps running in Qubes templates? The biggest vector to mitigate is the shared
X Window server X11. Is flatseal the best way to do this? Or is there another method like containerization
using systemd-nspwan? When attempting to revoke X11 permissions in favor of Wayland when using
flatseal, many apps simply will not boot. Is there a way of creating a list of apps that use Wayland over X11?

I’m unsure if I understand this dilemma correctly…

Just don’t run apps in templates - install them only; then create several domains for separating these applications?

Or do you want to sandbox applications running in one AppVM for some reason?

You shouldn’t be running apps in templates in the first place. Templates are for installing (and maybe configuring or customizing) apps. App qubes based on those templates are for running the apps.

Once you’ve got that down, the best way to sandbox is simple: Use different app qubes.

This mitigates the shared window system issue ? (X11)

Different domains run their own separate Xorg instances. Even if some malware gathered root privileges in one domain, it wouldn’t be able to capture any graphics and whatnot from another one.

In order to do that, it would need either a Xen exploit or a sneaky way of capturing something let’s say feedback from a microphone.

That’s also the reason why there’s passwordless sudo: Passwordless root access in qubes | Qubes OS - and also the reason why I can browse shady websites with Internet Explorer 11 in DisposableVMs and not worry about malware. :slight_smile:

1 Like

Any recent Xen exploits that you are familiar with?

Recently there were a few security advisories, but none of them is affecting Qubes OS.

I’m not familiar with anything else that could exploit Xen in this case.

QubesOS has been compiled for ARM? Since when?

Not - not Qubes. That’s the whole point :stuck_out_tongue:

That notice clearly states that those XSAs DO NOT affect the security of Qubes OS. For one of them, the reason it does not affect the security of Qubes OS is because it affects only the ARM architecture. (I thought I had already gone overboard with making this announcement template as clear as possible, but apparently it’s still not enough…)


If you’re referring to what I think you’re referring to, then Joanna wrote an interesting blog post about this (and how Qubes protects against it while regular Linux distros don’t) way back in 2011!


Once you’ve got that down, the best way to sandbox is simple: Use different app qubes.

And bonus points if the app qube is a disposable vm (even a named one).

I’m relatively new to this but I’m up to about 80 qubes now…including templates, DVM templates, and regular AppVM Qubes. It’s only going to get more extreme from here as I switch more and more to named DVMs (because the named DVM ends up as a qube, at least in the GUI, unless you generate it completely on the fly every time).

1 Like

130, with about 20-30 to delete after finishing switching to f36/deb12 minimals, only 3 AppVMs: vault, cacher and personal (lazy at the moment to edit file in it in dispvm). Everything else in dispvms.

1 Like

Are we up to debian 12? If so how on earth did I miss that?

We’re not, but you can upgrade to it

1 Like

We are not.
It is not likely to be released until 2023.
You can try it as “testing” but you will find that things break.

Fair enough. I can wait.

I break enough stuff on my own! :smiley:

1 Like