Architecture Design Record - Configuration interface for signature handling

Problem

It should be configurable if crinit shall use/expect signed configurations. How that is done will have implications on usability and security. We should find a secure way with reasonable usability.

Influencing Factors

Assumptions

  • a secure boot scheme is used

Considered Alternatives

Option 1 - Configuration at build-time

The signature functionality can be activated or deactivated at build-time using compiler definitions.

Pros

  • simple implementation

Cons

  • Causes problems with packaging. We would need to maintain and install two different crinit packages depending if we want to use signatures or not.

  • testing more complicated if multiple binaries exist

Option 2 - Configured in global configuration

Crinit’s global configuration would be always verified and offer a runtime configuration to activate or deactivate signatures for task configurations.

Pros

  • simple implementation

  • uses already present configuration parser

Cons

  • impossible to have an unverified global configuration

Option 3 - command line argument

Crinit will accept command line arguments to activate or deactivate signatures.

Pros

  • flexible

  • easy to parse with getopt

  • extensible

Cons

  • unusual for an init system

  • awkward to use from bootloader perspective

Option 4 - parse Kernel command line

Parse Kernel command line with arguments like crinit.signatures={yes|no} and similar to configure signature.

Pros

  • implicitly secure if secure boot chain is used

  • reasonably easy to parse with re2c

  • easy to use from bootloader perspective

  • extensible

Cons

  • completely new parser code required

Decision

Option 4 is taken.