freedomofpress / qubes-template-securedrop-workstation

Build the base Qubes VM template for the SecureDrop Workstation

By contributing to this project, you agree to abide by our Code of Conduct.

qubes-template-securedrop-workstation

Repository for managing the TemplateVM RPM used by the SecureDrop Workstation in provisioning custom VMs.

Build instructions

Note that these instructions must be carried out on a Fedora-based Qubes VM. Building templates uses a substantial amount of disk space.

Set up build VM:

Set up a long-lived VM that you can use for building SDW templates. This should be a separate VM from the (Debian-based) sd-dev recommended in the SDW setup docs. You'll only need to perform this step once, although you should confirm whether your Fedora version remains current each time.

1. Create an AppVM based on the most recent fedora release: qvm-create --label purple --template fedora-XX sd-template-builder
2. Increase the disk size to at least 30GB (as the build uses over 20GB): qvm-volume resize sd-template-builder:private 20G
3. Clone this repository into the AppVM: git clone https://github.com/freedomofpress/qubes-template-securedrop-workstation

Automatic build

We maintain a wrapper script that handles the interoperation with the upstream qubes-builder logic. Typically, you'll need only this short-and-sweet workflow to build a new template RPM. If you encounter problems, see the manual build instructions below.

1. Run sudo dnf upgrade -y to ensure your machine is up to date.
2. make template
3. The Template RPM can be found in ./qubes-builder/qubes-src/linux-template-builder/rpm/

Testing changes to builder logic

The qubes-builder logic expects signed tags on the most recent HEAD commit of the target branch. The tag and commit must be present on the remote, i.e. this repository. Simply creating them locally isn't enough, you'll need to push them up to the remote. If you're making changes to the build logic in this repo, you won't have a prod-signed tag yet, since you're still testing! Create a test-only tag signed with your individual GPG key.

0. Make the changes you intend to test on a branch of this repo.
1. Edit securedrop-workstation.conf and set BRANCH_template_securedrop_workstation ?= <YOUR_BRANCH_NAME>
2. Edit build-workstation-template to include your individual fingerprint, so the tag can be verified
3. Create a signed tag on that branch: git tag -s $(date +%Y%m%d-test), and push to the remote
4. make template

As your make changes to the feature branch, you must update or replace the signed git tags, so that HEAD remains signed. There are settings such as LESS_SECURE_SIGNED_COMMITS_SUFFICIENT for the builder.conf, which may be useful for testing.

Manual build

The wrapper script can get out of sync with the qubes-builder logic (which isn't pinned via submodule, see relevant issue). If that happens, run through the steps manually. The steps below closely mirror the script logic within build-workstation-template, so compare with the latest there.

1. Import and trust the Qubes Master Key and the SecureDrop Release Signing Key to the local gpg keyring in your sd-template-builder AppVM.
2. Clone the qubes-builder repository
3. Change directories into the qubes-builder repo
4. Copy the securedrop-workstation.conf from this repo as builder.conf inside the qubes-builder repo
5. make about should return securedrop-workstation.conf
6. Run make install-deps
7. Run make get-sources
8. Run make qubes-vm
9. Run make template
10. The built template RPM will be in qubes-builder/qubes-src/linux-template-builder/rpm/noarch

Installation instructions

1. Copy the template to dom0:

qvm-run --pass-io sd-template-builder 'cat source/file/location' > destination/sdw.rpm
sudo dnf install sdw.rpm

2. Create a VM based on this template for testing:

qvm-create --template securedrop-workstation-buster test-sdw-buster --class AppVM --property virt_mode=hvm --property kernel='' --label green

Acknowledgments

This work was inspired by and reuses code from the Whonix Qubes template: https://github.com/adrelanos/qubes-template-whonix It is a derivative work under the GPL license, version 3 (see the files COPYING and GPLv3 for details)

qubes-template-securedrop-workstation's Issues

Rebuild TemplateVM with updated signing key

As part of the planned keyring rotation (freedomofpress/securedrop#5923), we need to update the signing key used in this template to the new key and fingerprint, and build an updated template.

Sub-tasks

• Resolve dual keyring problems (requires updates to build script) - #21
• Update documentation for template build procedures - #21
• Add a prod-signed tag on HEAD of main post-merge of changes above - https://github.com/freedomofpress/qubes-template-securedrop-workstation/releases/tag/0.2.3
• Build new TemplateVM RPM, save build logs: freedomofpress/securedrop-yum-test#26
• Sanity check the new RPM via manual installation and testing
• Sign that RPM with the test key, upload to yum-test (via https://github.com/freedomofpress/securedrop-workstation-dev-rpm-packages-lfs/) , and post build logs
• Perform clean install in staging environment, via yum-test, confirm client functionality
• Update the keyring tests in https://github.com/freedomofpress/securedrop-workstation/blob/46054d1607f863f24d4ebf6504681b44f83ee09f/tests/test_vms_platform.py#L120
• Promote RPM to prod and resign with new prod key - freedomofpress/securedrop-yum-prod#20

Signing key fetch logic uses old keyservers

The SecureDrop Release Signing key is fetched from pool.sks-keyservers.net:

qubes-template-securedrop-workstation/build-workstation-template

Line 39 in d68a2d5

gpg --homedir ${gpg_homedir} --keyserver pool.sks-keyservers.net --recv-key 22245C81E3BAEB4138B36061310F561200F4AD77 || exit 1;

We should change that to e.g. keys.openpgp.org, since that's what we recommend folks use in most contexts to fetch the key. Noticed this because the signing key expired today, and while we'd pushed a new version to keys.openpgp.org, we'd overlooked the older pools. That's now been resolved manually.

Remove expired/legacy signing key

The template is still installing and importing the expired signing key. While it's theoretically harmless since it's expired, we should remove it.

Builder logic should pin upstream dependencies

On the latest master branch, the make template operation fails:

Makefile:591: target 'mgmt-salt.grep' given more than once in the same rule
make[2]: Leaving directory '/home/user/qubes-template-securedrop-workstation/qubes-builder'
-> Building template buster (logfile: build-logs/template-buster.log)...
make[1]: *** [Makefile:320: template-local-buster+securedrop-workstation] Error 1
make[1]: Leaving directory '/home/user/qubes-template-securedrop-workstation/qubes-builder'
make: *** [Makefile:2: template] Error 2

Inspecting that log file, we see:

Reading package lists...
Building dependency tree...
Reading state information...
apt-transport-https is already the newest version (1.8.2.1).
qubes-vm-recommended is already the newest version (4.0.7-1+deb10u1).
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 qubes-img-converter : Depends: python3-qubesimgconverter but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
Removing 'local diversion of /sbin/initctl to /sbin/initctl.distrib'
make[2]: *** [Makefile:65: rootimg-build] Error 100
make[2]: Leaving directory '/home/user/qubes-template-securedrop-workstation/qubes-builder/qubes-src/linux-template-builder'

It looks like newer upstream changes have broken our template build logic, so let's investigate. There may be overrides that we can place in securedrop-workstation.conf, or perhaps we should pin a submodule of the qubes-builder repo.

Steps to reproduce

1. Configure an F31-based build environment, as described in the README.
2. Check out this repository, on the master branch
3. Run make template
4. Inspect ./qubes-builder/build-logs/template-buster.log, observe error

Auto-add checksum to logs when building a new workstation template?

Description

When you run make template a bunch of log files are created for you, see freedomofpress/build-logs@2b2738f and freedomofpress/build-logs@362d39d. We may need a reminder in the readme or we could automate adding the checksum to the make-template log file since the PR reviewer is going to manually verify it later.

`make template` fails with paxctl error

Parent issue: freedomofpress/securedrop-workstation#600

make template fails now because it can't seem to find paxctld. Note that as of today we are hosting paxctld here: https://apt.freedom.press/pool/main/p/paxctld/paxctld_1.2.5-1_amd64.deb (and on apt-test).

distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 securedrop-workstation-grsec : Depends: paxctld but it is not installable
E: Unable to correct problems, you have held broken packages.
Removing 'local diversion of /sbin/initctl to /sbin/initctl.distrib'
make[2]: *** [Makefile:66: rootimg-build] Error 100
make[2]: Leaving directory '/home/user/qubes-template-securedrop-workstation/qubes-builder/qubes-src/linux-template-builder'