rocodes
commented
9 months ago Just going to write a comment with some of the discussion points we had at the SD coworking week a couple weeks ago, in case they are helpful for your thinking on this.
We discussed a few themes, particularly: our priorities (eg security vs usability tradeoffs, or system properties we wanted to prioritize); and our assumptions (mostly expected use conditions). This was so that if we came to a technical decision, we could fall back on coherent/cohesive principles.
Our general direction I would say could be summarized like this (and it's based on conversations many folks have had already, so hat tip to @deeplow @eaon and others for thinking this through).
- Have clear boundaries between "VM management" (external: setup, config, rpc policy creation/mgmt) vs "VM configuration" (internal, specific files, scripts, etc).
- In particular, things needed inside vms belong in packages (And Salt/dom0 orchestration/copying individual files and scripts into place in VMs via salt formulas is sort of smell/anti-pattern).
- This principle almost maps to "anything the adminAPI can do is external, anything else is internal," except I'm not sure that the admin API can trigger VM updates, so it's not a perfect map but it's the right idea.
- A 'good' pattern: vm mgmt/orchestration/policy management (from more privilieged domain) -> install packages + write a read-only config to a VM that is read at start time (via qubesdb) -> start a service configured per-vm (via systemd).
- This works very nicely with disposable VMs
- Inter-VM communication: we still haven't discussed in detail any kind of standardizing/best practices around inter-vm communication, and I think this is where we have the most work to do.
- Relevant to DZ
- Relevant to many parts of SDW (proxy <-> tor and proxy <-> client; eventual client <-> dz; client <-> export)
- There are lots of open questions. (Use socket-based rpc services? use executables? Best practices for what is a service arg, what to write to stdout/err, how to pass the information we want back and forth?)
- Particularly if we are going to have multiple different ways to export files from SDW (eg: export to USB, "export" to dangerzone, export + print, export to whatever other tip management system) it would be nice if we had a semi-standard inter-vm communication format. And then any apps or VMs that want to become part of the SD/file sanitization ecosystem would need to implement that format.
Draft up the approach of multi-VM deployment for Dangerzone in Qubes. This will not include any actual implementation and whatever solution we have in the end should accommodate two use cases:
I made a post on the Qubes forum summarizes the possible approaches: What’s the Future Of Multi-VM Applications?
Subtopics: