<html><body><p><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></font></tt><br><tt><font size="2">> To: Brett Grandbois <brett.grandbois@opengear.com>, petitboot@lists.ozlabs.org</font></tt><br><tt><font size="2">> 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></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>> www.opengear.com</font></tt><br><tt><font size="2">> _______________________________________________<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>