-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests/nested, tests/lib/snaps: make core20-fde-dbx test more realistic, add required dependencies #14952
base: fde-manager-features
Are you sure you want to change the base?
tests/nested, tests/lib/snaps: make core20-fde-dbx test more realistic, add required dependencies #14952
Conversation
We also make the FDE state manager install the the backend function to be associated with the state.
Because we will need to enroll multiple keys, we need to make the first key at volume creation a bootstrap key that we remove in the end. This commit does not implement it, but it does add the abstraction where to allow us to do it.
When using FDE with hooks or tpm, modifying the run model in the boot partition should result in disk that does not unlock. A recovery must be used in that case.
Its use was removed in 3988a93 which was in PR canonical#11715
Also update github.com/mvo5/goconfigparser to latest.
`by-partuuid` does not make much sense because it uselessly assumes that it is a partition. Conceptually we should not care about it. It also makes the resolution more complex as we need to fetch information about the device which we do not really need at this point. It is more common to resolve by filesystem UUID than part UUID. For instance cryptsetup accepts path as `UUID=deadbeef-dead-dead-dead-deaddeafbeef`. But it does not accept this kind of syntax for partitions.
Stubs Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
… process being root Add a new access checker which verifies that the request is coming from a root user and if the process is a snap, a required interface is connected, with that snap present on the slot side. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
…ureboot key DBs Add a new endpoint for integration with a local manager of EFI secureboot key databases. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
This factors and simplifies the TPM and FDE Hook code together. This does not yet factor the key file base one.
* overlord/fdestate: keep FDE state up to date StartUp() initializes the empty profiles, and reseal updates them. * secboot: reexeport secboot's kernel-key-not-found error Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * overlord/fdestate: use correct mount point for ubuntu-data Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * overlord/fdestate: skip key verification when key not in keyring For interim compatibilty, the key used to unlock ubuntu-save may not be present in the kernel keyring, so allow key digest verification step to be skipped in such scenario. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * secboot: use secboot marshallers instead of encoding/json for PCR profiles Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> --------- Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> Co-authored-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* fixup! many: formatting improvements Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> --------- Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com>
…cal#14845) * many: add skeleton to expose encryption features for target install system Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * many: update install api to support passphrase authentication This just allows passing the authentication options during the setup-storage-encryption install step but the underlying passphrase support implementation is not there yet. Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! secboot: add AuthModePIN Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! client: add pin-auth feature enum Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! daemon: use field initializers for readability Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! o/devicestate: fix test matching old error message Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! daemon: drop default initialization values Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! many: move VolumesAuthOptions under gadget/device This avoids import snapd/secboot from the client package Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! many: mark setup task when volumes auth is set This protects against an unexpected restart of snapd where the cached auth options will not be there. In this case, the task should detect this and fail. Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! gadget/install: formatting improvements Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> --------- Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com>
…al#14849) * tests/lib/muinstaller: add passphrase authentication support Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! tests/lib/muinstaller: switch to latest install-api branch Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> * fixup! tests/lib/muinstaller: switch snapd lib to fde-branch Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com> --------- Signed-off-by: Zeyad Gouda <zeyad.gouda@canonical.com>
Final pieces of EFI DBX support in fdestate, which implement the following logical 'actions' triggered through the snapd API: 'prepare' - triggered before fwupd or other agent performs the actual update, results in resealing of keys with the content of the DBX update 'cleanup - triggered after the update has completed, results in resealing of keys with the current content of DBX 'startup' - triggered whenever said agent starts up, such that we can detect whenever an unexpected reboot occurred or the agent crashed/restarted, which may trigger a reseal if an update was previously started. The updates are tracked as 'external' operations in fdestate. * tests/nested/manual/core20-fde-dbx: spread test for DBX related operations Add a spread test for DBX related operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * overlord/fdestate: implement EFI DBX operations Implement operations for notifying snapd of changes to the EFI DBX. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests/nested/manual/core20-fde-dbx: spread test for DBX related operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests/nested/manual/core20-fde-dbx: spread test for DBX related operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests/nested/manual/core20-fde-dbx: spread test for DBX related operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests/nested/manual/core20-fde-dbx: spread test for DBX related operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests/nested/manual/core20-fde-dbx: spread test for DBX related operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/fdestate: implement EFI DBX operations Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> --------- Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
# run without snapshot mode | ||
qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 -cpu host -machine q35 -global ICH9-LPC.disable_s3=1 \ | ||
-drive file=./OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \ | ||
-drive file=./OVMF_VARS.test.fd,if=pflash,format=raw \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to always take the OVMF_VARS that comes from the OVMF_CODE.secboot.fd. The one without secboot, and enable secboot on it. Then that would answer the question: "how do we update OVMF_VARS for a new OVMF_CODE?"
# device configuration -> secure boot -> custom | ||
# 1. enroll PK | ||
# 2. enroll KEK | ||
# 3. enroll DB | ||
# 4. enroll DBX? | ||
|
||
# reset | ||
# pwoeroff | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we build efitools, we can create LockDown.efi
. Then we can create an startup.nsh
script that calls it then shutdown. We just need OVMF with a shell.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Import pre-built OVMF state file and data set required for dbx spread tests. The procedure for enrolling new keys cannot be easily automated, so prebuilt files is all we have for now. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
… with enrolled keys Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
… efi variables Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Update the test to be more realistic and perform an actual update of DBX EFI variable. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
96b4063
to
4d87c2c
Compare
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
This can benefit from #14960 |
7005c64
to
25f9119
Compare
The PR aims to make
tests/nested/manual/core20-fde-dbx
test more realistic by performing an update of DBX such that the effects of resealing the keys can be observed and confirmed.Unfortunately, this branch introduces some complexity. In order to be able to update DBX, the payload needs to be authenticated, and signed by enrolled keys. Since this cannot be easily performed during CI, the branch ships pre-built assets under
tests/lib/nested-assets/dbx
. Those include a set of keys used as PK, KEK, signing key, db key and a couple of exclusion keys, along with prebuilt payload for key enrollment. PK, KEK, DB, and initial dbx have all been enrolled to ovmf, and are stored in OVMF_VARS.test.fd.The branch also introduces a testing snap
test-snapd-efitools
which ships the content ofefitools
package. I have requested a name in the store and it is currently awaiting approval.Related: SNAPDENG-32510