Dear Qubes OS Users and Developer Team,
I am the developer of the https://codeberg.org/andersonarc/reliant-system project, which provides support for plausible deniability in Qubes OS via volatile dom0 and https://codeberg.org/shufflecake/shufflecake-c encryption system. As of now, it relies on separating qubes.xml into 'shards' located in each deniable volume and merging them during the initramfs stage, as well as applying patches to the core system in order to maintain a RAM-based dom0. Both of these methods are unreliable and that is not something I believe should be kept in a security-focused project. Given that both https://github.com/QubesOS/qubes-issues/issues/2402 and https://github.com/QubesOS/qubes-issues/issues/4982 have been explicitly requested by users, as well as https://forum.qubes-os.org/t/reliant-deniable-encryption-for-qubes-os , I would like to propose a set of changes to the https://github.com/QubesOS/qubes-core-admin codebase that would make this possible without relying on unstable workarounds. 1. Support for split qubes.xml. We need a robust way to dynamically pick up qubes from the following locations, /var/lib/qubes/qubes.xml for core domains, templates and sys-*, /run/shufflecake/sflc_X_X/qubes.xml for deniable domains. Currently this is handled by https://codeberg.org/andersonarc/reliant-system/src/branch/master/tools/surgeon-dissect and https://codeberg.org/andersonarc/reliant-system/src/branch/master/tools/surgeon-suture . The locations are hardcoded into the script. My proposal is as follows, Designate the qubes.xml in /var/lib/qubes as authoritative, Establish a non-authoritative XML format as a set of <domain> entries, Allow the original qubes.xml or other configuration file deemed appropriate to link to an additional root folder, Recursively load additional domains.xml files within the linked folder. We could modify https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/app.py in qubesd to support sharding on both save and load. Otherwise, there could be an official tool to merge and split qubes.xml which respects any changes to the format. However, I believe the former would be both easier to implement and more robust, despite requiring changes to a core system component. 2. Randomized qube IDs. Sequential qube IDs will leak information about the presence of qubes in 'gaps' when the system is booted under duress. Current workaround is to programmatically change them in the XML files. A better solution would be to modify https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/app.py to provide randomized QIDs from a CSPRNG following a collision check with existing identifiers. In order to avoid confusing existing users, this feature should be highly optional. Existing qube IDs can be left as-is. 3. create-snapshot must respect rw="False". Otherwise, create-snapshot fails for large images (>~2 GB) such as templates under volatile dom0. For images tagged as rw="False", https://github.com/QubesOS/qubes-core-admin/blob/main/linux/system-config/create-snapshot should invoke losetup with the --readonly flag. The condition is to be identified within https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/storage/file.py and passed to create-snapshot as a commandline argument. Since readonly images must not be modified, this should not contain any breaking changes and can be seamlessly implemented without opt-in flags. 4. Copying between qubes in deniable volumes must be forbidden. Suppose you copy any file from a hidden qube 'secret' to a public qube 'work'. This will clearly reveal the source of the copied files as ~/QubesIncoming/secret, and the worst part is that even when you delete this directory, there will be forensically visible traces in the filesystem journal. Therefore, this must be strictly forbidden. I believe this can be handled via a tagging policy in Qubes RPC, but I will need to look deeper into that. The main point is that there must be a policy filter which can be applied based on storage pools (same/different) or an equivalent measure. An alternative solution could be to optionally obfuscate the source qube name in Qubes RPC for the target qube. Please share your thoughts on the matter and consider whether these features would be welcome in the codebase. If approved and we agree on an approximate implementation course, I will be ready to start working on individual PRs for each one. Kind regards, Anderson Rosenberg -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/19c2c13ba68.56953e3b246045.132967367640633435%40arcscience.org.
