nicoo

The AppArmor team meets in the pub and plans world domination. When: from 7pm to 8pm. Where: UCT Pub

How do people trust a service that you run? They could blindly trust that you are both honest and competent, but they shouldn't have to and you might not want to be trusted [0]. This BoF is meant for people providing (or using?) services over the network, to third-parties, and want to do so as transparently as possible.

• Step 0 is simply running free software: how could one trust the service without even knowing what it does?
  Yet, the software itself is not enough: whether it performs as intended (in the scope of the service) and securely depends on its configuration.
• The next step should be to document the setup, and publish the documentation.
  Unfortunately, documentation will get out of sync with the configuration, as it is wont to do.
• Then, it seems intuitive to publish the configuration (as in, the entire /etc directory), likely kept in version control. The solution I have used so far is simply keeping /etc versionned in git, using etckeeper, and automatically pushing the modifications to a public repository.

This approach also brings some unexpected benefits:

• It make it very easy to (re)build the same infrastructure, even if it involves several systems.
  This is a boon, both for automated testing and for users who decide they wish to self-host the same setup.
• Users can actually contribute back configuration changes, as patches/pull requests.
  They are not passive consumers anymore.
• It is extremely convenient to use this mechanism to manage the configuration of several servers running the same service (with the same config).

Some challenges I have been facing:

• How to handle secrets? (cryptographic keys, credentials, ...)
• How to handle automatic upgrades? (In the multi-server case)
• How to prove to the user that the configuration that is published is was is actually being run?

[0] By some weird cultural quirk, “trusted” is usually seen as a positive adjective. Yet, “X is trusted” means “X can break your security if compromised”: the less trust there is in a system, the more resilient it is.

Secure Boot is a UEFI feature that prevents unsigned boot code from being loaded. Assuming the bootloader checks the signature on the kernel, and the kernel checks the signature on code it itself loads, this chain of trust can be extended quite far into the running system. Unfortunately, the only signing key that is trusted by most implementations is held by Microsoft.

There are 2 major reasons for supporting Secure Boot in Debian:

• some computers now ship with Secure Boot enabled by default, making it harder to install Debian;
• while not perfect, it is a technology that can be used to make Debian user safer.

The plan the Ben (bwh) has been hatching is as follows:

• a minimalistic shim bootloader is signed by Microsoft;
• the shim load a bootloader that was properly signed by Debian (in the long run, ftpmaster@; right now, it's bwh's signing key);
• the bootloader loads a kernel signed by Debian;
• the kernel only accepts to load code signed by Debian (securelevel = 1).

The signing process itself uses signature packages, so as not to keep signing keys on the buildds or break reproducibility.

Advantages:

• no dependency on Microsoft, once the shim is signed (and it should need fixes very seldom);
• robust process that can take advantage of reproducible builds;
• gives reasonable guarantees that the running kernel is a legitimate one;
• trusting only Debian (as opposed to anything Microsoft signs) can easily be achieved by shipping a Debian-signed shim and having the user put the Debian key as the only trusted one.

Caveats:

• doesn't protect the userspace (yet!);
• still vulnerable to somebody with a kernel exploit (but this doesn't grant persistence) or who can get a bootloader signed by Microsoft.

Help us, fellow Debian hackers! You are our only hope.