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: