If my understanding is correct–that SDW is just a multi-VM application that runs on top of Qubes OS, would it be possible to create an SDW package that a Qubes user installs like any other template/app at some point in the future?
Also, would it be possible to create other multi-VM applications using the SDW framework? As in, create a new category of Qubes-only software that are all-in-one multi-VM packages you download from whatever repo and install as a single unit.
For example, if you want to use Qubes OS as a secure browser, you download the Firefox-Q package and it is basically a collection of VMs managed with a unified (or multi window) UI. Aside from dealing with wi-fi and VPN credentials, everything needed to make that stack run is there–from sys-net to sys-firewall to sys-vpn to sys-browser, and more if desired. Same with mail, word processing, etc. A rough sketch with lots of holes (like multiple sys-nets), but you see my point.
Having this as an option would greatly improve UX IMO.
I was heavily inspired by @Kog’s post, which talked about the possibility of other multi-VM applications which I assumed meant other SDW-like, specialized and fortified applications.
Since I’ve been thinking a lot about UX inside this form and beyond, I just generalized the idea to lighter uses like browsing. Don’t know if that counts as having a great mind, but yours definitely is since you’re working on it!
I’d help if I had the expertise, but I don’t have the relevant technical proficiencies. Where can I stay tuned?
Good question. I’ll post in this forum as soon as I have something interesting to share.
When it comes to the SecureDrop team, I’ll let them talk about plans they may have. (I am only aware of some of it, and definitely cannot speak for them. I’ll ping some folks privately see if they want to chime in at this point of the conversation.)
Also noticing that from post #9 the conversation could be split as a distinct topic. I’d say something along the lines of “Qubes OS-only software: all-in-one-package multi-VM applications”… @moderators
Well, some steps towards such a thing have happened, such as split-browser. There is a VM which is persistent (stores your bookmarks) and fires up disposable browsers (it can even configure them to some extent). The disposable can request a popup of bookmarks (running on the “master” VM); you select one and it is sent to the disposable. The disposable never sees all of your bookmarks.
That’s probably as tightly integrated inter-VM comms as I’ve seen so far (but I haven’t seen SecureDrop yet). Certainly it’s a good first step.
My split-veracrypt involves many VMs but is a lot more loosely integrated, largely because the clients are “other” VMs that presumably have apps, etc. on them rather than VMs that were designed solely to be clients as is the case of split-browser.
We’re facing similar questions (re)integrating Dangerzone into Qubes. For those that don’t know Dangerzone is a tool that brought Qubes Trusted PDF-like features to non-Qubes platforms. But it added extra stuff like OCR and compression, that’s kind of required for journalists to be able to their job. It was originally built by Micah Lee.
In the first stage, it’ll be as simple as the Qubes-trusted-PDF. But as a third-party application multi-vm setups are awkward at first because the user has to add policies to dom0 or pass code onto dom0 (as is the case for the SecureDrop workstation).
One big problem
The one of the bigger challenges, I think, is how to update the VM architecture / Qrexec calls
If we only ask the user to add a certain line to the dom0 qrexec policies for allowing the conversion to take place, what happens when we decide that we need to expand on that qrexec policy? Or add arguments, for example?
Asking the user to run some extra dom0 commands may work well for a technical audience. But what if the user is someone who is not very technical and who had somone else setup Qubes computer for them? Telling a user to dig into the plumbing on dom0 is not only very poor UX but also risky.
Solution 0 | Code in Dom0
By far the easiest approach install code in the user’s dom0. In the case of the SecureDrop workstation, this seems like a fine approach. On the one hand, it’s installed on dedicated journalist workstations and on the other, the SDW was really the first (and biggest AFAIK) multi-VM application.
However, it requires full trust in the developers of the application. This may work well for the SDW but it doesn’t scale very much for other projects.
In Dangerzone we already have our work cut out at least when it can probably latch onto the Workstation (when Dangerzone gets integrated into it).
Solution 1 | Qubes-team-sanctioned dom0 code
One way to have the code / policies updated in dom0 in a way that you don’t have to increase your THB (“Trusted Human Base” – the number of humans whom you have to trust to affect security-critical parts of the system) is to have the Qubes team audit your code and packaged as a Contributed Package.
This code part could be minimal, if we’re only talking about policy stuff. But again, it doesn’t scale well if the number of inter-VM applications were to grow bigger.
Solution 2 | Salt Distribution Method
As far as I understand this is akin to solution 1. It requires having effectively code that could in dom0 or at the very least affect the security of any of your VMs. So you need to fully trust it. Maybe an implementation could put scopes in place to make this secure, but I’m not convinced yet that this could solve the trust issue.
Furthermore, salt can be cumbersome to troubleshoot and rather slow. I’ll leave here a couple of links to related discussions:
Solution 3 | Admin API
I think the future of multi-qube applications lies in the use of the Qubes Admin API. I haven’t explored it much, but from what I understand, you can give a qube once access to manage policies and create other qubes and you’re done in that front. From then on, then the qube make use of the originally granted (and security scoped) permissions to manage its children without the need for user intervention. It can create more VMs, configure them and change the policies, if your application’s architecture ever changes.
I hear that the SecureDrop workstation already does a bit of this:
We actually use the Qubes Admin API a bit (via qvm-clone) when setting up the Qubes version of the SecureDrop server staging environment (which would be another multi-vm example, though not as useful a one).
For those unfamiliar with it, classic SecureDrop consists of an application and monitor server behind a firewall. Both are provisioned via Ansible, so we have a staging env for testing purposes, provisioned using the same roles and so forth. Since most SD devs are on Qubes now, we have a version of that env using standalone VMs: Virtual Environments: Using Qubes — SecureDrop Developer Docs latest documentation
But this is developer-oriented, so we haven’t made too much of an effort to simplify it, it’s possible you could make it a lot easier to set up via the Admin Api and package setup scripts.
Has there been any talk about creating a dedicated, lightweight dom0 for each multi-VM app, that runs on top of dom0 proper?
I’m not talking about another Xen, but just having the center of control for the multi-VM app in the app-dom0, which is immutable, ephemeral/disposable, generated by dom0 proper (i.e. controlled by the Qubes Team), and manages communications between the two, handling installation, sanitizing commands, etc. Changes to, say, qrexec are kept clean in this way. Somewhat similar to the Salt management VM, I think? (Not familiar)
I can see issues with figuring out what commands are clean and not, but for basic functionalities like browsing, the required set of commands should be limited. Since the goal is for a more user-friendly system for a wider audience, I’m not thinking about apps as fortified and involved as SDW, which can be considered an edge case in this context (though I think there can be special accommodations like a key for trusted developers or manual approval in these cases).
If that’s not possible, what about some sort of unikernel(?) that acts as the manager for the app and handles communications with dom0? Or some other sort of insulating layer?
The general idea is that dom0 wraps every app, compartmentalizing it and protecting itself–if every app is self-sufficient, then no app needs to communicate with one another outside of sanctioned and regulated methods like qvm-copy.
This might not be what you mean, but the administration of one (or multiple) VMs can be delegated by dom0 to another VM using QVM tags and RPC policies.
I cannot find it at this time, but the SecureDrop Workstation has some RPC policies that allow a given VM to execute parts of the Admin API against other VMs, as long as those VMs are tagged with a specific tag.
The policies and the ability to tag VMs are controlled by dom0, but most of the asministration can otherwise be delegated to the designated “admin VM”.
That is something that could, I believe, be used to reduce an application’s footprint in dom0. (By footprint I mean the amount of code that needs to be placed in dom0.)
I had totally forgotten about this part. I adjusted my original post to reflect the fact that the workstation also makes use of some Admin API stuff. But just like you, I couldn’t find the code either.
Tagging is used in SDW in a couple of different ways, for example to manage cut-n-paste policies. But IIRC that’s not via an admin VM, it all happens in dom0 during the provisioning steps.
It’s exciting to see this discussion here. After last September’s Qubes OS Summit, I analyzed the current beta version of the SecureDrop Workstation in terms of the so-called “twelve-factor methodology” for server applications, in order to test how applicable these high-level architectural concepts from the server and “cloud-native” worlds might be to a multi-VM application on Qubes. I also speculated about what it might mean for an application to be affirmatively “Qubes-native”, beyond being merely compatible with running inside a Qubes VM.
I’ve made this working paper available as a GitHub gist for review and comment:
This specifically is the motivation for New qrexec policy format · Issue #4370 · QubesOS/qubes-issues · GitHub. It allows putting all application-specific policies in one file, even if they cover multiple qrexec services. There are also qrexec services to control the policy itself but note they do give full control over specific policy snippet (there is no filtering what services you specify there, or what qubes it affects) - so, it isn’t suitable for not-fully-trusted applications, yet.
Ah, then I have misread the Admin API docs. I was under one could scope the Admin API in a way that it would be a certain “management” qube that would be running the policy daemon for certain scoped policies requested by a certain managed qube. But this is not the case as the docs clearly state:
Maybe this delegated qrexec-policy-daemon could be a solution to allow relatively untrusted “management” qubes to manage ones created by them and be the arbitrers of said policies.
Anyways, food for thought. I’ll need to play around a bit with the admin API to see what’s currently possible.
