On 15/10/2020 18:52, Mike Snitzer wrote: > On Thu, Oct 15 2020 at 11:05am -0400, > Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > >> From: Mickaël Salaün <mic@xxxxxxxxxxxxxxxxxxx> >> >> Add a new configuration DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING >> to enable dm-verity signatures to be verified against the secondary >> trusted keyring. Instead of relying on the builtin trusted keyring >> (with hard-coded certificates), the second trusted keyring can include >> certificate authorities from the builtin trusted keyring and child >> certificates loaded at run time. Using the secondary trusted keyring >> enables to use dm-verity disks (e.g. loop devices) signed by keys which >> did not exist at kernel build time, leveraging the certificate chain of >> trust model. In practice, this makes it possible to update certificates >> without kernel update and reboot, aligning with module and kernel >> (kexec) signature verification which already use the secondary trusted >> keyring. >> >> Cc: Alasdair Kergon <agk@xxxxxxxxxx> >> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> >> Cc: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> >> Cc: Jaskaran Khurana <jaskarankhurana@xxxxxxxxxxxxxxxxxxx> >> Cc: Mike Snitzer <snitzer@xxxxxxxxxx> >> Cc: Milan Broz <gmazyland@xxxxxxxxx> >> Signed-off-by: Mickaël Salaün <mic@xxxxxxxxxxxxxxxxxxx> >> --- >> >> Previous version: >> https://lore.kernel.org/lkml/20201002071802.535023-1-mic@xxxxxxxxxxx/ >> >> Changes since v1: >> * Extend the commit message (asked by Jarkko Sakkinen). >> * Rename the Kconfig "help" keyword according to commit 84af7a6194e4 >> ("checkpatch: kconfig: prefer 'help' over '---help---'"). > > Can you please explain why you've decided to make this a Kconfig CONFIG > knob? Why not either add: a dm-verity table argument? A dm-verity > kernel module parameter? or both (to allow a particular default but then > per-device override)? The purpose of signed dm-verity images is to authenticate files, or said in another way, to enable the kernel to trust disk images in a flexible way (i.e. thanks to certificate's chain of trust). Being able to update such chain at run time requires to use the second trusted keyring. This keyring automatically includes the certificate authorities from the builtin trusted keyring, which are required to dynamically populate the secondary trusted keyring with certificates signed by an already trusted authority. The roots of trust must then be included at build time in the builtin trusted keyring. To be meaningful, using dm-verity signatures implies to have a restricted user space, i.e. even the root user has limited power over the kernel and the rest of the system. Blindly trusting data provided by user space (e.g. dm-verity table argument, kernel module parameter) defeat the purpose of (mandatory) authenticated images. > > Otherwise, _all_ DM verity devices will be configured to use secondary > keyring fallback. Is that really desirable? That is already the current state (on purpose). > > Regardless, I really don't see why a Kconfig knob is appropriate. Moreover, a Kconfig knob makes sense as much as DM_VERITY_VERIFY_ROOTHASH_SIG, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY, MODULE_SIG_FORCE and other similar authentication mechanisms. Indeed, when using these configurations, we want the kernel to enforce a specific policy. Obviously, we can't make the DM_VERITY_VERIFY_ROOTHASH_SIG relies on the secondary trusted keyring without important security implications for systems already using this configuration (and then the builtin trusted keyring as the unique source of trust).
