From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
Date: Thu, 17 Oct 2013 23:44:05 +0200 [thread overview]
Message-ID: <52605A25.5040300@gmail.com> (raw)
In-Reply-To: <CADtfRCUUA_h4+VmoBiSj+qX2FD-XrQMqFcW8nSboo0ZoRNGyZA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]
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
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
next prev parent reply other threads:[~2013-10-17 21:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 18:28 RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'? Jonathan McCune
2013-10-17 21:44 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-10-18 2:44 ` Andrey Borzenkov
2013-10-21 17:33 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-10-21 17:44 ` Jonathan McCune
2013-10-21 21:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52605A25.5040300@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).