* RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
@ 2013-10-17 18:28 Jonathan McCune
2013-10-17 21:44 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan McCune @ 2013-10-17 18:28 UTC (permalink / raw)
To: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
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 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
[-- Attachment #2: Type: text/html, Size: 2477 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
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
2013-10-18 2:44 ` Andrey Borzenkov
0 siblings, 1 reply; 6+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-17 21:44 UTC (permalink / raw)
To: grub-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
2013-10-17 21:44 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-10-18 2:44 ` Andrey Borzenkov
2013-10-21 17:33 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 6+ messages in thread
From: Andrey Borzenkov @ 2013-10-18 2:44 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]
В Thu, 17 Oct 2013 23:44:05 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> 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
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
2013-10-18 2:44 ` Andrey Borzenkov
@ 2013-10-21 17:33 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-10-21 17:44 ` Jonathan McCune
0 siblings, 1 reply; 6+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-21 17:33 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]
On 18.10.2013 04:44, Andrey Borzenkov wrote:
> В Thu, 17 Oct 2013 23:44:05 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
>
>> 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.
>
I didn't oppose to a command or options having the described
functionality. Thinking about it, I have to agree that default behaviour
should be paranoid with options to relax it. Would you or Jonathan
prepare a patch to change the behaviour with an option to restore
current behaviour?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
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
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan McCune @ 2013-10-21 17:44 UTC (permalink / raw)
To: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
On Mon, Oct 21, 2013 at 10:33 AM, Vladimir 'φ-coder/phcoder' Serbinenko <
phcoder@gmail.com> wrote:
> On 18.10.2013 04:44, Andrey Borzenkov wrote:
> > В Thu, 17 Oct 2013 23:44:05 +0200
> > Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> >
> >> 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.
> >
> I didn't oppose to a command or options having the described
> functionality. Thinking about it, I have to agree that default behaviour
> should be paranoid with options to relax it. Would you or Jonathan
> prepare a patch to change the behaviour with an option to restore
> current behaviour?
>
How about addressing this by adding a --skip-sig option to both trust and
verify_detached, that disables signature checking for the loaded public
key? This would be similar in structure to the --skip-sig option to
load_env, and the consistent use of --skip-sig would hopefully make things
easier on the author of a .cfg file. It's mildly confusing to say
verify_detached --skip-sig since the whole point of that command is to
check a signature, but the documentation can make it clear.
I can prepare a patch but it could be a week or more before I have time to
do so.
Thanks,
-Jon
[-- Attachment #2: Type: text/html, Size: 2827 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
2013-10-21 17:44 ` Jonathan McCune
@ 2013-10-21 21:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 0 replies; 6+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-10-21 21:42 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1.1: Type: text/plain, Size: 2656 bytes --]
On 21.10.2013 19:44, Jonathan McCune wrote:
> On Mon, Oct 21, 2013 at 10:33 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com <mailto:phcoder@gmail.com>> wrote:
>
> On 18.10.2013 04:44, Andrey Borzenkov wrote:
> > В Thu, 17 Oct 2013 23:44:05 +0200
> > Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com
> <mailto:phcoder@gmail.com>> пишет:
> >
> >> 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.
> >
> I didn't oppose to a command or options having the described
> functionality. Thinking about it, I have to agree that default behaviour
> should be paranoid with options to relax it. Would you or Jonathan
> prepare a patch to change the behaviour with an option to restore
> current behaviour?
>
>
> How about addressing this by adding a --skip-sig option to both trust
> and verify_detached, that disables signature checking for the loaded
> public key? This would be similar in structure to the --skip-sig option
> to load_env, and the consistent use of --skip-sig would hopefully make
> things easier on the author of a .cfg file. It's mildly confusing to
> say verify_detached --skip-sig since the whole point of that command is
> to check a signature, but the documentation can make it clear.
>
> I can prepare a patch but it could be a week or more before I have time
> to do so.
>
Patch attached. Completely untested. Anyone to test it?
> Thanks,
> -Jon
>
>
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #1.2: pkcheck.diff --]
[-- Type: application/x-patch, Size: 3277 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-10-21 21:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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).