signed-boot verify_signature hole?

Sat Mar 17 07:42:05 AEDT 2018

Brett Grandbois <brett.grandbois at opengear.com> wrote on 03/14/2018 05:38:56
PM:

> From: Brett Grandbois <brett.grandbois at opengear.com>
> To: George Wilson <gcwilson at us.ibm.com>, Samuel Mendoza-Jonas
<sam at mendozajonas.com>
> Cc: Claudio Carvalho <cclaudio at linux.vnet.ibm.com>,
petitboot at lists.ozlabs.org, Stewart Smith
> <stewart at linux.vnet.ibm.com>, tpearson at raptorengineering.com
> Date: 03/14/2018 05:39 PM
> Subject: Re: signed-boot verify_signature hole?
>
> 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

Hi Brett,

The work hasn't been committed for a particular date yet.  I'd like to see
basic function available
by 4th quarter of this year.  But that isn't firm.

Regards,
George

>
> 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/20180316/d50bea84/attachment.html>