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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.