Create configuration packages for managing server settings

[conorsch]

Feature request

Description

FPF currently maintains a number of Debian packages for SecureDrop. Updates to those packages are applied nightly via cron-apt. For more substantial configuration changes, we request that Admins use the securedrop-admin script to apply changes interactively. That's a painful workflow, and does not allow for timely unattended updates.

We should build and maintain configuration packages, e.g. securedrop-base or securedrop-config, so that we can apply more comprehensive changes to the system state without requiring Admins to run commands from Tails.

One prominent example is switching the apt config to use an FPF mirror of the Tor Project repo (#2106). The implementation proposed in #2113 uses the postinst script in the securedrop-app-code Debian package to perform the keyring changes—and therefore only affects the Application Server, not the Monitor Server. We can do better.

Similarly, we've recently applied PaX flags and sysctl overrides in the securedrop-grsec metapackage. That intentional overloading was deemed acceptable given the need to ensure a timely response to security issues, and to ensure stability in the deployment (e.g. the PaX flags applied to grub binaries).

User Stories

As a SecureDrop Admin, I don't want to apply manual changes to my SecureDrop instance regularly. Booting the Tails Admin Workstation, verifying the latest key, and rerunning a playbook is time-consuming, error-prone manual process.

As a SecureDrop maintainer, I want to ship timely updates to instances and rest assured they will be applied across the managed hosts. The changes should be implemented in a way that is accessible and intelligible to project contributors, not scattered across a number of different git repositories.

[conorsch]

Working on this now, focusing on the Tor apt mirror (#2106). Will write new tests to confirm apt URLs are correct and keep working on the package until all tests pass.

[conorsch]

Likely going to violate some of the Debian packaging guidelines to make this work, e.g. we'll be writing repo source information inside /etc/apt/sources.list.d. Those violations go against the grain of #1637, but I consider them a temporary measure until we move from Trusty to Xenial (#1530), at which point we can start with a relatively clean slate.

[conorsch]

The new securedrop-config package presented in #2113 is not technically a "config package" in Debian jargon, but rather a old-style package with no debhelper integration, that simply lays down required files much like the securedrop-keyring package already does. This is fine for now, but during the move to Xenial, we should consider massaging the packaging story further.

[zenmonkeykstop]

Another approach to this problem was proposed in #3136 - the issue as a whole bears further discussion (would be amazing to get in for Focal migration, tho definitely a stretch goal at this point).