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