signed-boot verify_signature hole?

Thu Mar 15 09:38:56 AEDT 2018

Hi George,

That all sounds great to me, and all roughly in the direction(s) we were 
planning to go.

I know this is a sort of 'how long is a piece of string?' question, but 
any rough idea on time lines?

Brett

On 14/03/18 09:48, George Wilson wrote:
>
> Samuel Mendoza-Jonas <sam at mendozajonas.com> wrote on 03/12/2018 
> 09:32:04 PM:
>
> > From: Samuel Mendoza-Jonas <sam at mendozajonas.com>
> > To: Brett Grandbois <brett.grandbois at opengear.com>, 
> petitboot at lists.ozlabs.org
> > Cc: tpearson at raptorengineering.com, Claudio Carvalho 
> <cclaudio at linux.vnet.ibm.com>, George Wilson
> > <gcwilson at us.ibm.com>, Stewart Smith <stewart at linux.vnet.ibm.com>
> > Date: 03/12/2018 09:32 PM
> > Subject: Re: signed-boot verify_signature hole?
> >
> > 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?
>
> Here are the current plans.  The usual disclaimer that none of this is 
> set in stone applies.
>
> OpenPOWER OS secure boot will offer a key management interface via the 
> Petitboot UI.  Admins will manage their own
> keys and determine which ones they want to trust without having to go 
> back to a central authority.  Keys will be stored
> in PNOR flash and checked against a hash kept securely in the TPM. 
>  Petitboot will enforce a signature check via a secure
> kexec and have the ability to reject unsigned or improperly signed 
> kernels.  We're working with Linux distributions to
> make signed kernels available out of the box but we will also make it 
> easy for admins to sign their own kernels or
> disable secure boot entirely if they don't want it.
>
> The Petitboot secure boot changes will be modular and non-OpenPOWER 
> users will be able to deselect them if they
> aren't used on a particular platform.  One thing we need to implement 
> in order to control access to secure boot
> configuration data is a login to Petitboot - that may be more 
> generally useful than other changes we're making
> depending on how portable password store ends up.
>
> So far as the initramfs goes, we're excluding it for now.  That's 
> because there are legitimate reasons for the
> initramfs to be rebuilt and we consider it volatile for our purposes. 
>  We could verify its contents with
> IMA-appraisal if/when the kernel can support xattrs in its cpio format 
> that would allow us to lay down IMA-appraisal
> file signatures.  There are likely other approaches but that seems the 
> most viable to us at the moment.
>
> We'd eventually like to lock down the Petitboot shell.  A restricted 
> shell or actually running processes under
> different uids for privilege separation and requiring sudo might be 
> interesting.  If we have IMA-appraisal,
> we could require that downloaded binaries be signed.  Maybe even 
> mandatory access control - SELinux or AppArmor -
> would be appropriate.  We haven't thought it through but reducing 
> general admin privilege should make managing
> the system more secure.
>
> >
> > 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/20180315/07f8817d/attachment-0001.html>