WIP: remote signing and signature generalization #2

Draft
raito wants to merge 15 commits from signing-client into master
Owner

This PR is composed of ~four changes:

  • generalization of signature schemes in the tool
  • generalization of how to assemble stubs in the shared library
  • a remote signature server that sends you signed stub in exchange for signature requests
  • an implementation inside lzbt-systemd of remote signing

This enables moving the local signature to another server… or even maybe a hardware security token!

In the future, the server can ask for attestations or any kind of things to give the signed stub.

Note

Initrd secrets are not supported by the remote signer

This is out of scope for this PR and will probably not supported as I plan to bring systemd credentials
first inside of NixOS and remove the legacy initrd secrets which are a broken feature.

What were alternatives?

  • Offer a way to send the secret to the signer: NAK because an attacker could present a secret being a trivial privilege escalation binary.
  • Force the secret to be present on the signer: NAK because this would require at least a policy to allow / disallow access to a given secret based on the requester, this is too big for this PR.
    Therefore, initrd secrets will NOT work with the remote signer.
This PR is composed of ~four changes: - generalization of signature schemes in the tool - generalization of how to assemble stubs in the shared library - a remote signature server that sends you signed stub in exchange for signature requests - an implementation inside lzbt-systemd of remote signing This enables moving the local signature to another server… or even maybe a hardware security token! In the future, the server can ask for attestations or any kind of things to give the signed stub. > [!NOTE] > #### Initrd secrets are not supported by the remote signer > This is out of scope for this PR and will probably not supported as I plan to bring systemd credentials > first inside of NixOS and remove the legacy initrd secrets which are a broken feature. > #### What were alternatives? > - Offer a way to send the secret to the signer: NAK because an attacker could present a secret being a trivial privilege escalation binary. > - Force the secret to be present on the signer: NAK because this would require at least a policy to allow / disallow access to a given secret based on the requester, this is too big for this PR. > Therefore, initrd secrets will *NOT* work with the remote signer.
Now, it is possible to build any package of the workspace in a fine grained fashion.
We want here to capture the required data to assemble a stub, here is a partial structure
modulo ESP generation paths.

Other pieces of code can consume this structure, validate it before passing it to the PE assembler
and the signer.

We convert everything into owned structures because we cannot really do
deserialization in any context with lifetimes going around, but,
allocations are generally very cheap in this context.
In order to offer more flexible signature mechanisms in lanzaboote,
we need to take a step back and offer a general PE signature trait.

After this, we will be able to plug various different implementations.
Remote signing enables a user to request for:

- PE signature of a given store path, which is assumed to be available on the server side
- PE signature oi a stub given by its parameters, which are assumed to be analyzable on the server side
  (i.e. computing hashes is possible.)
- Verifying if a PE signature is correct according to PE signatures and Secure Boot policy
It is now possible to use remote signature inside lzbt-systemd.
This is an example server to perform remote signatures
based on stub parameters provided.
Our lanzaboote integration tests are getting more and more sophisticated and ambitious.

Let's extract them into a "lanzalib", so they can be used with multiple backends.
We build lanzasignd now as part of the flake as an additional software we provide.
Introduces the Secure Boot remote signing server for NixOS.
Lanzaboote boot module now supports using a potential remote signer server,
but this support is limited to the lanzaboote bootables and not the fwupd ones.
A simple test harness for remote signatures with lanzasignd.
We didn't test if there *was* a signature, idempotency of removal of signatures (i.e. removing an non-existent signature
is the identity operation) could fool us into believing we had a signed thing then not signed.
This is relevant for a remote signer who relies on the existence of store paths
remotely, for example.
We fabricated a lot of initrds which were exactly the same as the one in
our store when we had no initrd secrets. This ends this practice.
personal todo:

- returns stub parameters in the toplevel setup
- verify paths for local keypair
- build and sign a stub, verify it using the API, verify it locally (?)
- build a stub, sign a "store path" (actually a temporary location on the same system), verify it using the API
- sign a random file, verify it using the API
This pull request has changes conflicting with the target branch.
  • flake.nix
  • nix/modules/lanzaboote.nix
  • nix/tests/lanzaboote.nix
  • rust/tool/Cargo.lock
  • rust/tool/shared/Cargo.toml
  • rust/tool/shared/src/pe.rs
  • rust/tool/shared/src/signature/local.rs
  • rust/tool/shared/src/signature/mod.rs
  • rust/tool/systemd/src/cli.rs
  • rust/tool/systemd/src/install.rs
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin signing-client:signing-client
git switch signing-client

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master
git merge --no-ff signing-client
git switch signing-client
git rebase master
git switch master
git merge --ff-only signing-client
git switch signing-client
git rebase master
git switch master
git merge --no-ff signing-client
git switch master
git merge --squash signing-client
git switch master
git merge --ff-only signing-client
git switch master
git merge signing-client
git push origin master
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-community/lanzaboote#2
No description provided.