Investigate remote administration

[joshuathayer]

Part of the reason we decided to target Qubes 4 for the workstation release was to potentially use its admin VM / remote administration features to allow us to keep client installations updated.

Since Qubes is approaching stability, investigate how we may be able to use this feature: its abilities, its security tradeoffs, its applicability to our use case.

[eloquence]

We've aimed to keep maintenance requirements minimal, and are handling updates through a preflight updater that's started on each workstation boot. That said, providing remote admin tooling may still be worth considering in our threat model (e.g., to deal with any kind of system breakage), so keeping this old issue open pending input from other team members.

[conorsch]

Since this issue was opened, Qubes has added a GUI updater, and we've added our own GUI updater specifically for the SDW (mostly for UX niceties such as a progress bar, as well as to force updates on net-less VMs, which wouldn't ordinarily appear in the GUI updater). So keeping instances up to date is largely achieved now, although we'll certainly try to smooth out that process as time goes on.

admin VM / remote administration features to allow us to keep client installations updated.

My interpretation of this phrasing is a recommendation to explore the Admin API https://www.qubes-os.org/doc/admin-api/, not to allow geographically distributed access for instance Admins to log into a Workstation to help debug a problem a journalist is having. Geographic distribution remains a challenge for deployments, but we're currently providing support directly to journalists in the pilot, with Admins in the loop.