grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

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