Enable avahi qubes service in support of driverless printing

[deeplow]

• I have searched for duplicates or related issues

Description

Driverless printing support (i.e. the modern equivalent to linux printer drivers) is already under way on the client (see freedomofpress/securedrop-client#2332). It relies on the avahi-daemon systemd services as well as CUPS. All can be implemented at the template level, but we need the avahi qubes service on sd-devices so that the avahi-daemon can start.

How will this impact SecureDrop/SecureDrop Workstation users?

If anything, it should improve the printer compatibility of the workstation. Most modern printers do support AirPrint and unlinke linux compatibility, AirPrint is actively advertised by manufacturers on the product's boxes. Traditionally, the workstation has only supported a significantly limited number of printers and the prospect of being able to use more printers should be positive. However, no all printers will be compatible, since we'll still require USB connections.

How would this affect the SecureDrop Workstation threat model?

The current threat model implicitly assumes trust on the USB devices, regarding access to sd-devices (the VMs where the USB is attached to), confirmed per discussion with the team. Driverless printing via USB, exposes sd-devices slightly more.

In this sense, threats introduced by malicious printers or any other USB devices remain the same, or exfiltration vectors such as WiFi on printers, should be mitigated by the organizations using SecureDrop.

User Stories

As a workstation admin, I want to be able to procure compatible printers easily.

[rocodes]

(I added the "blocked" label temporarily just so that we don't merge this before we cut the 1.1.0 release, but as soon as that's out of the way I will remove label, review+merge)