On 17.10.2013 20:28, Jonathan McCune wrote: > Presently the 'trust' and 'verify_detached' commands disable all filters > (e.g., verify.c:grub_cmd_trust() calls grub_file_filter_disable_all()) > when opening a file containing a public key (note the distinction from > verify_detached implicitly using an already-loaded key).
This is the intended behaviour. Usecase to manually add keys when needed. Your proposal is for other usecases which would probably require special arguments or separate functions. > This makes it > cumbersome to construct a public key hierarchy at boot time, by loading > other signed public keys. To do this securely, the author of grub.cfg > would need to explicitly invoke 'verify_detached' (using an implicit > public key that was embedded in core.img using "grub-mkimage --pubkey") > and check the return value before invoking 'trust'. > > Arguments in favor of trust respecting 'check_signatures=enforce' (i.e., > making a change): > * Consistency with behavior in nearly all other file-opening scenarios > when check_signatures=enforce > * Results in cleaner grub.cfg files > > Arguments against (i.e., leaving things as-is): > * Desired functionality can already be obtained with appropriate script > code in grub.cfg > * Makes it impossible (unless I'm missing something) to experiment with > check_signatures=enforce without first providing a public key using the > --pubkey option to grub-mkimage (and presumably soon grub-install). > * Most users will never look at the C code but will see grub.cfg, and it > may be useful to put the public key validation logic right in front of > their eyes > > As I mistakenly assumed that 'trust' *did* respect > 'check_signatures=enforce' upon first encountering this code, I tend to > favor the position that this is the preferred functionality. I think > the right way to proceed is probably: (1) fix grub-install to support > --pubkey, (2) alter the behavior of 'trust' and 'verify_detached' to > respect 'check_signatures=enforce', and then (3) update the > documentation to make this clear. > > As mentioned, the desired functionality can be obtained either way, so > as I currently understand things this is more a matter of aesthetics > than functionality. Note that grub.cfg files that manually validate > public keys before loading them would continue to behave correctly in > the face of these changes (though their validation efforts would be > redundant). > > Best, > -Jon > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
