Explore Immutable Templates in Qubes #1486
Description
Description
Immutable Desktop Operating Systems have been maturing over the last decade, but often it becomes cumbersome for users to customize and troubleshoot. But in our specific use-case of the workstation, this does not appear to be a constraint. As opposed to generic OSes, our templates are not supposed to be user-managed.
Using immutable templates would give us more guarantees over the exact state of templates, making sure we don't have to account for lingering state. The same logic for templates can be expanded to app qubes and disposables. The use of explicit volumes for user-data would give developers the ability to rebuild the entire system on updates, leaving user-data securely isolated in their own volumes.
If this were to be implemented, it would likely have to be in Qubes itself, if there is the openness for that. It would be an alternative (a possible complement) to the existing template storage management.
A few related links for further exploration:
- https://github.com/bootc-dev/bootc - booting from containers
- https://lwn.net/Articles/979182/
- https://lwn.net/SubscriberLink/1042708/4400bd7207e45ba9/
Looping in @legoktm and @apyrgio who contributed to this discussion.
(Note: I coudn't find any reference of immutable templates on qubes-issues, but I may have no looked hard enough and I have not yet covered the forum nor qubes-devel)
How will this impact SecureDrop/SecureDrop Workstation users?
- (+) Nullifies the risk of templates fully breaking on updates (see our preemptive fix to avoid such a situation)
- (+) Less storage consumed (sharing of layers among templates)
- (-) Updates may be more bandwidth-intensive (depending on implementation)
(extra) how will it affect Qubes users:
- regular templates would operate as they have, but there would be an additional immutable template update mechanism
How would this affect the SecureDrop Workstation threat model?
TBD