Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?

[Andrey Borzenkov]

В Thu, 17 Oct 2013 23:44:05 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:

> 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 has the same MITM problem we already discussed and that was fixed
if pubkey filter is used - you cannot actually know that key you trust
is the same as key you verified. So I think that at least by default
"trust" should not disable pubkey filter.

verify_detached probably should, but may be only for file that is
verified itself, bit for pubkey.

> >  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. 

Two step approach (verify than trust) is susceptible to MITM. Less
relevant for disks, but quite so for networks.

>                         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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> > 
> 
>

signature.asc
Description: PGP signature