Qubes OS support

[ypid]

As I have been managing my workstations with Ansible and DebOps for some time now and have migrated to Qubes OS I will be working on some level of support for it for DebOps. My use case for Qubes OS is as a workstation/end point so I will probably not work much on dedicated server roles.

To configure Qubes OS TemplateVMs and AppVMs, some ground work has been made, first and foremost Ansible support for Qubes OS itself ansible-qubes. ansible-qubes is not officially supported by Qubes OS and currently does not have the same advanced integration and security as Salt in Qubes OS.

On the DebOps side of things, some ground work is needed to make changes in TemplateBasedVMs persistent. The role for it is ready: debops.persistent_paths. @drybjed Can we move the role to DebOps core, so that it can be used from other DebOps core roles? Example: debops.cryptsetup

[drybjed]

I haven't used Qubes OS myself so I wonder how do you use Ansible/DebOps with it. Presumably you apply DebOps on a template VM image which is then started as needed? Therefore the persistent paths will be useful with more roles than just debops.cryptsetup.

I don't really like the role name to be honest, it results in stuff like persistent_paths__persistent_paths which sounds horrible. :-) Because the role manages the Qubes OS bind-dirs.sh script, perhaps a better name will be something like debops.qubes_bind_dirs which would result in qubes_bind_dirs__persistent_paths? Keep in mind that I'm assuming that you will want to add this role to more DebOps playbooks in the future.

I'm also not sure about the placement of the persistent_paths__qubes_os_enabled variable and wrapping the whole role in a conditional. I suppose that you took that approach so that activation/deactivation of the role could be done based on wether the OS is Qubes or not and this condition is defined in just one place (the role itself), so let's go with it. But, I think that the variable should be renamed to persistent_paths__enabled or in the new scheme, qubes_bind_dirs__enabled because its function is akin to similar variables in other DebOps roles. The condition in the variable is fine.

Since the topic of this issue is broad, can you tell me more about the things you want to include in DebOps to make it work better with Qubes? I wonder about the built-in Salt interface in Qubes, does it apply changes to the started VMs just after boot or do you need to start that by hand? Do you think that adding configuration via Salt which is applied after the VM is booted automatically might be a better idea than needing to apply the changes manually?

[ypid]

My use case is that I have multiple TemplateVMs but I only run Ansible and DebOps against less trusted VMs. For more trusted TemplateVMs, I basically configured the few things I needed manually to keep the TCB as minimal as possible.

I don’t run the full DebOps common playbook against my templates because I don’t need it. Currently, I run the following DebOps core roles:

[debops_service_core:children]
my_workstation_qubes_managed_templates

[debops_service_apt_preferences:children]
my_workstation_qubes_managed_templates

[debops_service_apt:children]
my_workstation_qubes_managed_templates

[debops_service_apt_proxy:children]
my_workstation_qubes_managed_templates

[debops_service_resources:children]
my_workstation_qubes_managed_templates

[debops_service_users:children]
my_workstation_qubes_managed_templates

So TemplateVMs are basically normal Debian 8 VMs where you can Ansible and DebOps against without much of a difference (there are differences like APT repos and default packages that sometimes need to be handled specially, ref: ypid.packages).

Then I use multiple AppVMs based on those templates. In the AppVMs, only a few paths are persistent as documented and I split the inventory for my bare metal workstation to the different AppVMs. The idea is that the AppVMs are then provisioned one time using some Ansible roles and then left alone (ref: Salt integration in Qubes OS, Threat Model). So I would like to be able to rebuild an TemplateVM or AppVM quickly and have them documented.

About the name, you are right. persistent_paths__persistent_paths is terrible. But I think I have an easy fix for this: I just changed persistent_paths__persistent_paths to persistent_paths__paths. I actually started the role by the name debops.qubes_os_bind_paths and did go through a few iterations until I had the idea that this role should be generic and not specific to Qubes OS. I am quite happy with the role name so far and would like to avoid to go back to something like debops.qubes_bind_dirs. Keeping the role generic is a key point here. The role provides a generic interface for other roles to say which files and directories are required to be persistent. It is the same with persistent_paths__qubes_os_enabled, basically a second namespace for the Qubes OS related settings of the role. The role can have support for multiple systems which handle persistent paths in different ways. This will keep it future proof.
persistent_paths__qubes_os_enabled is more used to detect if the Qubes OS specific part of the role should run against the host. So an additional persistent_paths__enabled could be added but I don’t really see the need for it as the role is by itself optional which can be controlled by Ansible host groups, refer to the cryptsetup example. Sure, the role is focused on Qubes OS currently, but persistent paths in itself are not and other systems similar to Qubes OS could pop up or already exist (I guess OpenXT does not have a similar feature but could potentially have it). I just wanted to avoid all the renaming stuff by abstracting from the concrete implementation. debops.cryptseutp does not need to know that it just configures persistent path on Qubes OS, all the role wants is persistence for a few paths :)

About the Salt support. I have took my time to get into it and actually use it to define all my TemplateVMs and AppVMs from the outside (e. g. dom0), but nothing inside those VMs. I am not used to Salt yet and have everything ready with Ansible, so I started with Ansible but I might get into Salt more. This is an example of my Salt configuration which creates an AppVM based on a Debian 8 template:

Create d-web:
  qvm.present:
    - name: d-web
    # Only set initially and is then not updated but is required:
    - label: red

Configure d-web:
  qvm.prefs:
    - name: d-web
    - template: t-deb-8-full
    - netvm: s-vpn
    - label: blue

For you question, Qubes OS is smart enough to start VMs before trying to talk to the agent inside the VM. The following command was run against a VM which was shutdown:

$ time ansible appvm-based-on-deb-8-min -m ping
appvm-based-on-deb-8-min | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
ansible appvm-based-on-deb-8-min -m ping  1.69s user 0.81s system 19% cpu 12.609 total

Qubes OS automatically started the VM and Ansible waited with execution.

About automatic execution, I don’t mind that much about that and don’t need my CM system to make automatic changes without me triggering them.

cc @Rudd-O you might also be interested in this.

[drybjed]

@ypid The repository has been moved to the debops organization. Do you want to check anything else, or can I relese the first version? Currently waiting for your debops-playbooks PR to pass the test on Travis.

[ypid]

Thanks. You can release the first version when you want. Will add it to docs later.

[ypid]

Qubes OS support works and has been tested on Qubes OS R3.2 and R4.0. Closing as implemented.