-
Notifications
You must be signed in to change notification settings - Fork 300
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
composefs: Change how we do signatures
Currently we generate a signature for the actual composefs image, and then we apply that when we enable fsverity on the composefs image. However, there are some issues with this. First of all, such a signed fs-verity image file can only be read if the corresponding puiblic keyring is loaded into the fs-verity keyring. In a typical secure setup we will have a per-commit key that is loaded from the initrd. Additionally, the keyring is often sealed to avoid loading more keys later. This means you can only ever mount (or even look at) composefs images from the current boot. While this is not a huge issue it is something of a pain for example when debugging things. Secondly, and more problematic, during a deploy we can't enable fs-verity on the newly created composefs file, because and at that point you need to pass in the signature. Unfortunately this will fail if the matching public key is not in the keyring, which will fail for similar reasons as the first issue. The current workaround is to *not* enable fs-verity during deploy, but write the signature to a file. Then the first time the particular commit is booted we apply the signature to the iamge. This works around issue two, but not issue one. But it causes us to do a lot of writes and computation during the first boot as we need to write the fs-verity merkle tree to disk. It would be much better and robust if the merkle tree could be written during the deployment of the update (i.e. before boot). The new apporach is to always deploy an unsigned, but fs-verity enabled composefs image. Then we create separate files that contain the expected digest, and a signature of that file. On the first boot we sign the digest file, and on further boots we can just verify that it is signed before using it. This fixes issue 1, since all deploys are always readable, and it makes the workaround for issue 2 much less problematic, as we only need to change a much smaller file on the first boot. Long term I would like to avoid the first-boot writing totally, and I've been chatting with David Howells (kernel keyring maintainer) and he proposed adding a new keyring syscall that verifies a PKCS#7 signature from userspace directly. This would be exactly what fs-verity does, except we wouldn't have to write the digest to disk during boot, we would just read the digest file and the signature file each boot and ask the kernel to verify it.
- Loading branch information
1 parent
bb4a89e
commit 99ba5c4
Showing
4 changed files
with
204 additions
and
76 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters