signed-boot verify_signature hole?

[George Wilson]

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/20180313/8c4fbc0e/attachment-0001.html>