<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi George,</p>
<p>That all sounds great to me, and all roughly in the direction(s)
we were planning to go.</p>
<p>I know this is a sort of 'how long is a piece of string?'
question, but any rough idea on time lines?</p>
<p>Brett<br>
</p>
<br>
<div class="moz-cite-prefix">On 14/03/18 09:48, George Wilson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:OFD5B3A40F.E8F01B83-ON8625824F.007B0ED6-8625824F.0082C994@notes.na.collabserv.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p><tt><font size="2">Samuel Mendoza-Jonas
<a class="moz-txt-link-rfc2396E" href="mailto:sam@mendozajonas.com"><sam@mendozajonas.com></a> wrote on 03/12/2018 09:32:04
PM:<br>
<br>
> From: Samuel Mendoza-Jonas <a class="moz-txt-link-rfc2396E" href="mailto:sam@mendozajonas.com"><sam@mendozajonas.com></a></font></tt><br>
<tt><font size="2">> To: Brett Grandbois
<a class="moz-txt-link-rfc2396E" href="mailto:brett.grandbois@opengear.com"><brett.grandbois@opengear.com></a>,
<a class="moz-txt-link-abbreviated" href="mailto:petitboot@lists.ozlabs.org">petitboot@lists.ozlabs.org</a></font></tt><br>
<tt><font size="2">> Cc: <a class="moz-txt-link-abbreviated" href="mailto:tpearson@raptorengineering.com">tpearson@raptorengineering.com</a>,
Claudio Carvalho <a class="moz-txt-link-rfc2396E" href="mailto:cclaudio@linux.vnet.ibm.com"><cclaudio@linux.vnet.ibm.com></a>, George
Wilson <br>
> <a class="moz-txt-link-rfc2396E" href="mailto:gcwilson@us.ibm.com"><gcwilson@us.ibm.com></a>, Stewart Smith
<a class="moz-txt-link-rfc2396E" href="mailto:stewart@linux.vnet.ibm.com"><stewart@linux.vnet.ibm.com></a></font></tt><br>
<tt><font size="2">> Date: 03/12/2018 09:32 PM</font></tt><br>
<tt><font size="2">> Subject: Re: signed-boot
verify_signature hole?</font></tt><br>
<tt><font size="2">> <br>
> On Mon, 2018-03-12 at 10:01 +1000, Brett Grandbois
wrote:</font></tt><br>
<tt><font size="2">> Hi,</font></tt><br>
<tt><font size="2">> We're looking at adopting the
signed-boot system in our platform and going through the
implementation I've noticed <br>
> something I need to ask the wider community about. In
lib/security/gpg.c in gpg_validate_boot_files() the initial
<br>
> commit had this code block:</font></tt><br>
<tt><font size="2">> + if
(verify_file_signature(kernel_filename,<br>
> + local_image_signature,<br>
> + authorized_signatures_handle, "/etc/gpg"))<br>
> + result = KEXEC_LOAD_SIGNATURE_FAILURE;<br>
> + if (verify_file_signature(cmdline_template,<br>
> + local_cmdline_signature,<br>
> + authorized_signatures_handle, "/etc/gpg"))<br>
> + result = KEXEC_LOAD_SIGNATURE_FAILURE;</font></tt><br>
<tt><font size="2">> where the following commit that adds in
the decryption support removes the: </font></tt><br>
<tt><font size="2">> result = KEXEC_LOAD_SIGNATURE_FAILURE;</font></tt><br>
<tt><font size="2">> lines to the kernel and command line
checks, effectively making them irrelevant in the
boot_task->verify_signature path?</font></tt><br>
<tt><font size="2">> Is there some other check somewhere else
that I've missed?</font></tt><br>
<tt><font size="2">> <br>
> Hi Brett,</font></tt><br>
<tt><font size="2">> <br>
> No, looks like you've found a legitimate bug. Those if
statements will fall through to the initrd signature check,</font></tt><br>
<tt><font size="2">> making it possible to boot with an
invalid kernel and command line.</font></tt><br>
<tt><font size="2">> In the short term we should obviously
fix that. Longer term I reckon it's worth thinking about
how/if we use and</font></tt><br>
<tt><font size="2">> consume the signed boot code.</font></tt><br>
<tt><font size="2">> <br>
> The signed/encrypted boot code was added in 2016 by
Timothy (CC'd) mainly for their TALOS OpenPOWER P8</font></tt><br>
<tt><font size="2">> machine. That didn't fully ship AFAIK
and focus moved to TALOS II (P9). So while the
signed/encrypted boot code</font></tt><br>
<tt><font size="2">> has been tested and checked by myself
and Timothy, I don't know anyone that's actually used this
in any</font></tt><br>
<tt><font size="2">> seriousness, and I'm not sure whether
the Raptor Engineering people intend to use it for TALOS II
- Timothy can you</font></tt><br>
<tt><font size="2">> weigh in on that?</font></tt><br>
<tt><font size="2">> <br>
> 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.</font></tt><br>
<tt><font size="2">> How that fits in next to what we have
now or whether we should see if one should replace the other
are questions that</font></tt><br>
<tt><font size="2">> have been the back of my mind.</font></tt><br>
<tt><font size="2">> George and Claudio - would you mind
giving us a brief rundown for the benefit of the Petitboot
list of how IBM's</font></tt><br>
<tt><font size="2">> secure/trusted boot process will work,
and the main ways that could impact Petitboot specifically?</font></tt><br>
<tt><font size="2">> Additionally how will IBM's
implementation affect users such as Brett who are using
Petitboot but are not running on a</font></tt><br>
<tt><font size="2">> POWER machine, ie. not OPAL?</font></tt><br>
<br>
<tt><font size="2">Here are the current plans. The usual
disclaimer that none of this is set in stone applies.</font></tt><br>
<br>
<tt><font size="2">OpenPOWER OS secure boot will offer a key
management interface via the Petitboot UI. Admins will
manage their own</font></tt><br>
<tt><font size="2">keys and determine which ones they want to
trust without having to go back to a central authority.
Keys will be stored</font></tt><br>
<tt><font size="2">in PNOR flash and checked against a hash kept
securely in the TPM. Petitboot will enforce a signature
check via a secure</font></tt><br>
<tt><font size="2">kexec and have the ability to reject unsigned
or improperly signed kernels. We're working with Linux
distributions to</font></tt><br>
<tt><font size="2">make signed kernels available out of the box
but we will also make it easy for admins to sign their own
kernels or</font></tt><br>
<tt><font size="2">disable secure boot entirely if they don't
want it.</font></tt><br>
<br>
<tt><font size="2">The Petitboot secure boot changes will be
modular and non-OpenPOWER users will be able to deselect
them if they</font></tt><br>
<tt><font size="2">aren't used on a particular platform. One
thing we need to implement in order to control access to
secure boot</font></tt><br>
<tt><font size="2">configuration data is a login to Petitboot -
that may be more generally useful than other changes we're
making</font></tt><br>
<tt><font size="2">depending on how portable password store ends
up.</font></tt><br>
<br>
<tt><font size="2">So far as the initramfs goes, we're excluding
it for now. That's because there are legitimate reasons for
the</font></tt><br>
<tt><font size="2">initramfs to be rebuilt and we consider it
volatile for our purposes. We could verify its contents
with</font></tt><br>
<tt><font size="2">IMA-appraisal if/when the kernel can support
xattrs in its cpio format that would allow us to lay down
IMA-appraisal</font></tt><br>
<tt><font size="2">file signatures. There are likely other
approaches but that seems the most viable to us at the
moment.</font></tt><br>
<br>
<tt><font size="2">We'd eventually like to lock down the
Petitboot shell. A restricted shell or actually running
processes under</font></tt><br>
<tt><font size="2">different uids for privilege separation and
requiring sudo might be interesting. If we have
IMA-appraisal,</font></tt><br>
<tt><font size="2">we could require that downloaded binaries be
signed. Maybe even mandatory access control - SELinux or
AppArmor -</font></tt><br>
<tt><font size="2">would be appropriate. We haven't thought it
through but reducing general admin privilege should make
managing</font></tt><br>
<tt><font size="2">the system more secure.</font></tt><br>
<br>
<tt><font size="2">> <br>
> Regards,</font></tt><br>
<tt><font size="2">> Sam</font></tt><br>
<tt><font size="2">> <br>
> -- <br>
> Brett Grandbois<br>
> Software Engineering<br>
> Opengear Inc.<br>
> <a class="moz-txt-link-abbreviated" href="http://www.opengear.com">www.opengear.com</a></font></tt><br>
<tt><font size="2">>
_______________________________________________<br>
> Petitboot mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Petitboot@lists.ozlabs.org">Petitboot@lists.ozlabs.org</a><br>
> <a href="https://lists.ozlabs.org/listinfo/petitboot"
moz-do-not-send="true">https://lists.ozlabs.org/listinfo/petitboot</a><br>
</font></tt><br>
</p>
</blockquote>
<br>
</body>
</html>