signed-boot verify_signature hole?

[Samuel Mendoza-Jonas]

On Mon, 2018-03-12 at 10:01 +1000, Brett Grandbois wrote:
>     Hi,
> 
>     We're looking at adopting the signed-boot system in our platform
>       and going through the implementation I've noticed something I need
>       to ask the wider community about.  In lib/security/gpg.c in
>       gpg_validate_boot_files() the initial commit had this code block:
> 
>     
>       
> > +    if
> >         (verify_file_signature(kernel_filename,
> > 
> >         +        local_image_signature,
> > 
> >         +        authorized_signatures_handle, "/etc/gpg"))
> > 
> >         +        result = KEXEC_LOAD_SIGNATURE_FAILURE;
> > 
> >         +    if (verify_file_signature(cmdline_template,
> > 
> >         +        local_cmdline_signature,
> > 
> >         +        authorized_signatures_handle, "/etc/gpg"))
> > 
> >         +        result = KEXEC_LOAD_SIGNATURE_FAILURE;
> 
>     
> 
>     where the following commit that adds in the decryption support
>       removes the:
>       
> > result = KEXEC_LOAD_SIGNATURE_FAILURE;
> 
>       lines to the kernel and command line checks, effectively making
>       them irrelevant in the boot_task->verify_signature path?
> 
>     Is there some other check somewhere else that I've missed?
> 
>     
> 
>     

Hi Brett,

No, looks like you've found a legitimate bug. Those if statements will fall through to the initrd signature check,
making it possible to boot with an invalid kernel and command line.
In the short term we should obviously fix that. Longer term I reckon it's worth thinking about how/if we use and
consume the signed boot code.

The signed/encrypted boot code was added in 2016 by Timothy (CC'd) mainly for their TALOS OpenPOWER P8
machine. That didn't fully ship AFAIK and focus moved to TALOS II (P9). So while the signed/encrypted boot code
has been tested and checked by myself and Timothy, I don't know anyone that's actually used this in any
seriousness, and I'm not sure whether the Raptor Engineering people intend to use it for TALOS II - Timothy can you
weigh in on that?

At the same time I'm aware of a lot of work going on by other IBMers to implement full-stack secure and trusted boot.
How that fits in next to what we have now or whether we should see if one should replace the other are questions that
have been the back of my mind.
George and Claudio - would you mind giving us a brief rundown for the benefit of the Petitboot list of how IBM's
secure/trusted boot process will work, and the main ways that could impact Petitboot specifically?
Additionally how will IBM's implementation affect users such as Brett who are using Petitboot but are not running on a
POWER machine, ie. not OPAL?

Regards,
Sam

>     
> 
>     
> 
>     
> 
>     -- 
> 
>       Brett Grandbois
> 
>       Software Engineering
> 
>       Opengear Inc.
> 
>       www.opengear.com
> 
>   
> 
> _______________________________________________
> Petitboot mailing list
> Petitboot at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/petitboot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/petitboot/attachments/20180313/fd25070d/attachment.html>