Since I first started using qubes, I make a copy of main template, put printer drivers on it and make dedicated dvm to use that template. I would right click document, open in dvm and print from there. I believe this is secure way of printing things.
Now, I’m printing many times a day and this process becoming time consuming, especially with different printers, different paper sizes etc. Moreover I will be having programs which will require ability to print things directly.
Is there any other secure way to print without having to go through so many steps? My network printers are blocked to the outside world by the router. Printer can be accesses from outside world though via VPN which is also controlled by the router. I’m not sure if this makes any difference.
Your current approach is solid from a security standpoint, but you’re right that it’s friction-heavy for frequent use. Let me walk through some options.
The core trade-off you’re making
Your DVM approach isolates the printer attack surface entirely — a malicious printer or compromised CUPS can’t touch your data qube. Any streamlining involves accepting some reduction in that isolation, so it’s worth being deliberate about what you’re comfortable with.
Option 1: A persistent, dedicated print qube (most practical improvement)
Instead of a DVM, use a persistent AppVM based on your printer template. You keep the same security model but eliminate the startup overhead and the need to reconfigure paper sizes/printer settings every time. You can pre-configure all your printers and settings in CUPS once, and they persist. You’d still right-click → open in qube, but the qube is already running and configured.
This is probably the biggest quality-of-life gain with minimal security regression. A persistent print qube is only marginally less secure than a DVM for this use case — the main risk a DVM protects against is state accumulation, which matters less when the qube’s only job is printing.
Option 2: Qrexec-based print service
You can set up a qrexec policy that allows specific qubes to send a file to the print qube automatically. A small wrapper script in your working qubes pipes a file to the print qube via qvm-run or a proper qrexec service, which then hands it to CUPS. This lets applications in your work qubes “print” without you manually copying files. The print qube still handles all printer communication. This takes some scripting to set up but is the cleanest long-term solution if programs need to print directly.
Option 3: Shared CUPS with firewall rules
You could run CUPS in a dedicated net-connected qube and allow specific AppVMs to reach it over Qubes internal networking. This is more conventional but means your work qubes have a direct network path to the printer qube, which widens the attack surface somewhat. Given that your printers are network-isolated from the outside world anyway, this is a reasonable middle ground many Qubes users accept.
On your network setup
The fact that your printers are blocked externally is a meaningful risk reduction — a printer being reachable from the internet is a real threat vector for firmware attacks. VPN access you control is fine. This doesn’t change the internal Qubes isolation question much, but it does mean your threat model is primarily about a compromised printer attacking back into your network, not an internet adversary pushing malicious firmware.
What I’d suggest
Start with the persistent print qube (Option 1) — it’s an afternoon of work and immediately cuts your friction significantly. If you need direct printing from applications, layer on a qrexec service (Option 2) on top of that. The combination gives you a clean, automated experience while keeping the printer fully isolated in its own qube.
There’s a reasonably detailed community guide on the qrexec approach on the Qubes forum if you want to go that route — searching “Qubes printing qrexec” should surface it. The Qubes docs also cover setting up qrexec services if you want to roll your own.