Last active
May 11, 2025 22:22
-
-
Save cfm/d6be88a4e11b66dfce4d382b668d276b to your computer and use it in GitHub Desktop.
Revisions
-
cfm revised this gist
May 23, 2023 . 1 changed file with 5 additions and 0 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -145,6 +145,9 @@ In addition to the limitations discussed above: architecture, such as network ACLs and service-specific policies in cloud environments?[^10] - Alternatively, this might call for a generalization of the "split" service architecture exemplified by [split GPG][qubes-split-gpg]. ## References - Randy Bias, ["The History of Pets vs Cattle and How to Use the Analogy @@ -179,6 +182,7 @@ In addition to the limitations discussed above: - Domenico Luciani, ["The Fifteen-Factor App"][luciani] - Qubes OS, ["Architecture"][qubes-os-architecture] - Qubes OS, ["Qrexec: Secure Communication across Domains"][qubes-os-qrexec] - Qubes OS, ["Split GPG"][qubes-split-gpg] - Joanna Rutkowska, ["How Is Qubes OS Different from..."][rutkowska] - Adam Wiggins, ["The Twelve-Factor App"][wiggins] - Wikipedia, ["Twelve-Factor App Methodology"][wikipedia-twelve-factor] @@ -200,6 +204,7 @@ In addition to the limitations discussed above: [qubes-issues-8138]: https://github.com/QubesOS/qubes-issues/issues/8138 [qubes-os-architecture]: https://www.qubes-os.org/doc/architecture/ [qubes-os-qrexec]: https://www.qubes-os.org/doc/qrexec/ [qubes-split-gpg]: https://www.qubes-os.org/doc/split-gpg/ [rutkowska]: https://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html [securedrop-973]: https://github.com/freedomofpress/securedrop/issues/973 [securedrop-client]: https://github.com/freedomofpress/securedrop-client -
May 17, 2023 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,285 @@ # Adapting the twelve-factor methodology for "Qubes-native" multi-VM applications: a preliminary sketch[^1] ## Introduction Virtualization is the _conceptual_ technology on which modern services (server applications) are built. Whether an application happens to run on a fully- or para-virtualized VM[^2] or is containerized—or even runs on a “bare-metal” physical server after all—most modern services are designed in isolated, replicated, disposable components on commodity hardware.[^3] The [“twelve-factor methodology”][wiggins] (2011) is an influential articulation of the principles that tend to be adopted, more or less explicitly, by applications designed and deployed in this way. [“Cloud-native”][grey] is a more-recent articulation and expansion of many of the same principles. Virtualization is also the conceptual as well as literal technology on which Qubes OS’s [security-by-compartmentalization][qubes-os-architecture] desktop (client-side) environment is built. However, because most Qubes users run “normal” Linux applications (Firefox, Thunderbird, Vocal, Hypatia, etc.) most of the time, there seems to be only niche interest in considering Qubes a unique environment for _designing_ desktop applications, not just for running them. If virtualization has been so influential in the evolution of _server-side_ architecture, we should wonder how it might also influence the evolution of _client-side_ architecture—at least for specialized applications, such as the [SecureDrop Workstation][fpf-design], that require its security properties in the first place. ## Working definitions and hypotheses **A “cloud-native” (server) application** consists of _isolated_, _replicated_, _disposable_ components that talk to one another in _predefined_ ways, especially with regard to the flow of data and the persistence of state. **A “Qubes-native” (desktop) application** consists of _isolated_, ~~replicated~~, _disposable_ components that talk to one another in _predefined_ ways, especially with regard to the flow of data and the persistence of state. **The factors** are implementation patterns that follow logically from these properties of _isolation_, _disposability_, and _predefinition_. Where these properties apply in common to “cloud-native” and “Qubes-native” applications, both classes of applications can follow these patterns and share tools[^4] to help implement them—even if they have different motivations for these properties. ## What is the “twelve-factor” methodology?[^5] > In the modern era, software is commonly delivered as a service: called web > apps, or software-as-a-service. The twelve-factor app is a methodology for > building software-as-a-service apps that: > > - Use declarative formats for setup automation, to minimize time and cost for > new developers joining the project; > - Have a clean contract with the underlying operating system, offering maximum > portability between execution environments; > - Are suitable for deployment on modern cloud platforms, obviating the need > for servers and systems administration; > - Minimize divergence between development and production, enabling continuous > deployment for maximum agility; > - And can scale up without significant changes to tooling, architecture, or > development practices. > > The twelve-factor methodology can be applied to apps written in any > programming language, and which use any combination of backing services > (database, queue, memory cache, etc). ## What are the twelve factors?[^6] | Factor | Description | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **1. Codebase** | There should be exactly one codebase for a deployed service with the codebase being used for many deployments. | | **2. Dependencies** | All dependencies should be declared, with no implicit reliance on system tools or libraries. | | **3. Configuration** | Configuration that varies between deployments should be stored in the environment. | | **4. Backing services** | All backing services are treated as attached resources and attached and detached by the execution environment. | | **5. Build, release, run** | The delivery pipeline should strictly consist of build, release, run. | | **6. Processes** | Applications should be deployed as one or more stateless processes with persisted data stored on a backing service. | | **7. Port binding** | Self-contained services should make themselves available to other services by specified ports. | | **8. Concurrency** | Concurrency is advocated by scaling individual processes. | | **9. Disposability** | Fast startup and shutdown are advocated for a more robust and resilient system. | | **10. Development/ production parity** | All environments should be as similar as possible. | | **11. Logs** | Applications should produce logs as event streams and leave the execution environment to aggregate. | | **12. Admin processes** | Any needed admin tasks should be kept in source control and packaged with the application. | Some subsequent articulations extend this model with additional factors, for example:[^7] | Factor | Description | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **13. API** | “Define the service contract first”[^11]; even first-party applications consume the same API as everyone else. | | **14. Telemetry** | Monitor holistic service “health” over time, not just errors and exceptions. | | **15. Authentication and authorization** | Authentication and access controls appropriate to every layer of the stack. | ## Which factors are and are not relevant in a Qubes OS desktop environment? | **LEGEND** | | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | ✓ | The factor is relevant in Qubes OS, and the SecureDrop Workstation currently makes use of it. | | ¾ | The factor is relevant in Qubes OS. The SecureDrop Workstation currently makes explicit use of it, with limitations or edge cases for future work. | | ½ | The factor is relevant in Qubes OS. The SecureDrop Workstation currently makes partial or implicit use of it and could expand it. | | ¼ | The factor is potentially relevant in Qubes OS, with caveats. | | ✗ | The factor is not relevant in Qubes OS. | Taking the current (→ idealized) SecureDrop Workstation as an example: | Factor | Application | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Codebase** | ✓—The `securedrop-{workstation,client,export,sdk,proxy}` repositories are used in all deployments, in all environments. | | **2. Dependencies** | ¾—The provisioned `sd-*` VMs and their installed packages manage most of their own dependencies independent of the underlying host, with some exceptions we hope to resolve. | | **3. Configuration** | ½—Variable configuration is injected into the `sd-*` VMs’ filesystems during installation and during any subsequent reconfiguration.<br><br>→ [securedrop-workstation#853][securedrop-workstation-853] will be unblocked by [QubesOS/qubes-issues#8138][qubes-issues-8138]. | | **4. Backing services** | ½—See (6) “Processes” for state-oriented and (7) “Port Binding” for action-oriented backing services. | | **5. Build, release, run** | ✗—Not applicable. A 12-factor release involves _pushing_ the output of a continuous-integration workflow into a continuous-deployment workflow. A Qubes-based application, like any native desktop application, will always be released by publishing an artifact for existing deployments to _pull_ and install locally. | | **6. Processes** | ½—The [SecureDrop Client][securedrop-client] application in the `sd-app` VM is highly stateful on files and a database on the same filesystem and mounted within the same VM as the running application.<br><br>→ These state-oriented functions could be abstracted out into other backing services to separate their concerns (and shrink their attack surfaces) further. | | **7. Port binding** | ½—The [SecureDrop Client][securedrop-client] application in the “air-gapped” (networkless) `sd-app` VM makes use of a couple of “external” services, which are provided by other VMs and called via [qrexec][qubes-os-qrexec] RPC calls rather than ports or sockets.<br><br>→ We’ve considered different approaches for generalizing these action-oriented functions to make them more robust and extensible. | | **8. Concurrency** | ¼—Potentially applicable, although concurrency on Qubes OS serves further isolation[^8] as much as increased performance. | | **9. Disposability** | ½—Disposable VMs are used to isolate “view” and “export” operations.<br><br>→ With backing stores and runtime configuration factored out, the service VMs running the [SecureDrop Client][securedrop-client] and [`securedrop-proxy`][securedrop-proxy] could also be stateless and disposable.<br><br>If _fully_ stateless and disposable, we could change our conceptual model for provisioning the Workstation from enforcing idempotent state (e.g., `salt state.highstate`) to either (a) replacing images and configuration in place or (b) wiping them and provisioning them from scratch every time (like `terraform destroy && terraform apply`). | | **10. Development/ production parity** | ✓—[Pretty much!][fpf-setting-up]—parameterized on which Yum and Apt repositories host and guest packages are fetched from, respectively. | | **11. Logs** | ✓—The `sd-*` VMs stream their logs to the `sd-log` VM, which is a log sink just like a syslog server. | | **12. Admin processes** | ½—Via `sdw-admin`, except for cases such as [clipboard policy][fpf-managing-clipboard] where we recommend the use of native Qubes tooling.<br><br>→ Further administration depends on further work on (3) “Configuration” and (4) “Backing Services”. | | **13. API** | ✓—The [SecureDrop Server][fpf-securedrop-docs]’s [Journalist API][fpf-journalist-api] is the foundation of the [SecureDrop Client][securedrop-client]. | | **14. Telemetry** | ¼—Potentially desirable for individual VMs but not for `dom0`, which in Qubes OS does not have network connectivity. Not applicable at all for the SecureDrop Workstation: For both technical and organizational security reasons, we’re no more likely to aggregate logs or telemetry for real-time monitoring of an organization’s SecureDrop Workstations than we are for on-contract SecureDrop Servers.[^9] | | **15. Authentication and authorization** | ✓—Yes, on a comprehensive and rigorous [threat-model][fpf-architecture]. | ## Conclusion The premise of the SecureDrop Workstation project is that [Qubes OS is a platform for building secure multi-VM applications][mz-43]. The _foundation_ of that platform—virtualization—is originally and fundamentally _server_ technology. [mz-43]: https://docs.google.com/presentation/d/1fNgXapTPn9O-jeFyPRpbByz8hAssFykeUvu0Q09khY8/edit#slide=id.g15005a58f84_0_1 Therefore, a secure multi-VM application such as the SecureDrop Workstation isn’t straightforwardly a “desktop” or “client” application. It’s a collection of “server” services—that just so happens to have a native GUI frontend served via the Qubes GUI subsystem, rather than a Web frontend served to a Web browser. ## For future work In addition to the limitations discussed above: - **Is there a Qubes-specific factor we can define,** such as inter-VM policy or permissions, either (a) beyond the standard configuration factor and the supplemental authentication/authorization factor or (b) by composing multiple factors? How might this factor be related to other trends in server and network architecture, such as network ACLs and service-specific policies in cloud environments?[^10] ## References - Randy Bias, ["The History of Pets vs Cattle and How to Use the Analogy Properly][bias] - Freedom of the Press Foundation, ["Alerting sent to admins / opt-in to SecureDrop team"][securedrop-workstation-22] - Freedom of the Press Foundation, ["Automatically send a subset of system alerts to FPF"][securedrop-973] - Freedom of the Press Foundation, ["Design of the Next-Generation SecureDrop Workstation"][fpf-design] - Freedom of the Press Foundation, ["Configure SecureDrop-proxy via QubesDB"][securedrop-workstation-853] - Freedom of the Press Foundation, ["Journalist Interface API"][fpf-journalist-api] - Freedom of the Press Foundation, ["Managing Clipboard Access"][fpf-managing-clipboard] - Freedom of the Press Foundation, [SecureDrop Client][securedrop-client] - Freedom of the Press Foundation, [securedrop-proxy][securedrop-proxy] - Freedom of the Press Foundation, ["SecureDrop Workstation Architecture"][fpf-architecture] - Freedom of the Press Foundation, ["Setting Up the SecureDrop Workstation"][fpf-setting-up] - Freedom of the Press Foundation, ["Welcome to SecureDrop's Documentation!"][fpf-securedrop-docs] - Invisible Things Lab, ["Implement a way for a qube to access (some) of its features"][qubes-issues-8138] - Tom Grey, ["5 Principles for Cloud-Native Architecture: What It is and How to Master It"][grey] - Grace Jansen, ["Beyond the 12 Factors: 15-Factor Cloud-Native Java Applications"][jansen] - Micah Lee, ["Allow bulk conversion to safe PDFs"][dangerzone-77] - Domenico Luciani, ["The Fifteen-Factor App"][luciani] - Qubes OS, ["Architecture"][qubes-os-architecture] - Qubes OS, ["Qrexec: Secure Communication across Domains"][qubes-os-qrexec] - Joanna Rutkowska, ["How Is Qubes OS Different from..."][rutkowska] - Adam Wiggins, ["The Twelve-Factor App"][wiggins] - Wikipedia, ["Twelve-Factor App Methodology"][wikipedia-twelve-factor] - Xen, ["Understanding the Virtualization Spectrum"][xen-understanding] - Michael Z., ["Building Secure Appliations with Qubes OS"][mz] [bias]: https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ [dangerzone-77]: https://github.com/freedomofpress/dangerzone/issues/77 [fpf-architecture]: https://workstation.securedrop.org/en/stable/admin/workstation_architecture.html [fpf-design]: https://securedrop.org/documents/13/SD_Qubes_Workstation_Whitepaper.pdf [fpf-journalist-api]: https://developers.securedrop.org/en/latest/journalist_api.html [fpf-managing-clipboard]: https://workstation.securedrop.org/en/stable/admin/managing_clipboard.html [fpf-securedrop-docs]: https://docs.securedrop.org [fpf-setting-up]: https://developers.securedrop.org/en/latest/workstation_setup.html [grey]: https://cloud.google.com/blog/products/application-development/5-principles-for-cloud-native-architecture-what-it-is-and-how-to-master-it [jansen]: https://developer.ibm.com/articles/15-factor-applications/ [luciani]: https://domenicoluciani.com/2021/10/30/15-factor-app.html [mz]: https://cfp.3mdeb.com/qubes-os-summit-2022/talk/WFVXPP/ [qubes-issues-8138]: https://github.com/QubesOS/qubes-issues/issues/8138 [qubes-os-architecture]: https://www.qubes-os.org/doc/architecture/ [qubes-os-qrexec]: https://www.qubes-os.org/doc/qrexec/ [rutkowska]: https://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html [securedrop-973]: https://github.com/freedomofpress/securedrop/issues/973 [securedrop-client]: https://github.com/freedomofpress/securedrop-client [securedrop-proxy]: https://github.com/freedomofpress/securedrop-proxy [securedrop-workstation-22]: https://github.com/freedomofpress/securedrop-workstation/issues/22 [securedrop-workstation-853]: https://github.com/freedomofpress/securedrop-workstation/issues/853 [xen-understanding]: https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum [wiggins]: https://12factor.net/ [wikipedia-twelve-factor]: https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology ## Changelog **16‒17 May 2023:** - Update and streamline for publication as a working paper. - Incorporate FPF contributions. - Convert to Markdown. **3 November 2022:** - Address FPF feedback. **26 October 2022:** - Add a footnote re: Salt. **19 October 2022:** - Clarify terminology. **13 October 2022:** Second draft. - Address “extra” factors beyond the original 12-factor model. - Expand working definitions and hypotheses, and address the distinction between implementation patterns and motivations. **6 October 2022:** First draft. [^1]: This working paper was inspired by Michael Z.’s talk on [“Building Secure Applications with Qubes OS”][mz] at the 2022 Qubes OS Summit; and has been further informed by ongoing discussions within the [SecureDrop] and [Dangerzone] teams at the [Freedom of the Press Foundation], where I work, and with the [Qubes OS] team at [Invisible Things Lab]. However, except where noted otherwise, the opinions and speculations expressed here are my own—as are all assumptions, limitations, and errors. [dangerzone]: https://dangerzone.rocks [freedom of the press foundation]: https://freedom.press [invisible things lab]: https://invisiblethingslab.com [qubes os]: https://qubes-os.org [securedrop]: https://securedrop.org [^2]: Xen, ["Understanding the Virtualization Spectrum"][xen-understanding]. [^3]: Bias, ["The History of Pets vs Cattle and How to Use the Analogy Properly"][bias]. [^4]: Qubes's use of Salt already proves this point: Salt is first and foremost a configuration-management tool for _servers_. [^5]: Wiggins, ["The Twelve-Factor App"][wiggins]. [^6]: Wiggins; Wikipedia, ["Twelve-Factor App Methodology"][wikipedia-twelve-factor]. [^7]: Jansen, ["Beyond the 12 Factors: 15-Factor Cloud-Native Java Applications"][jansen]. [^8]: Or usability: e.g., [bulk sanitization of documents][dangerzone-77]. [^9]: This has been discussed for both the [Workstation][securedrop-workstation-22] and the [Server][securedrop-973]. [^10]: This point comes from Ro S., who observes: “If you're thinking of making a [Q]ubes-native app, one of the first things you will have to think about is which domain will be responsible for what layer, and how you will enforce that with policy.” [^11]: Luciani, ["The Fifteen-Factor App"][luciani].