On Fri, Mar 3, 2017 at 5:20 PM, Ladi Prosek <lpro...@redhat.com> wrote: > On Fri, Mar 3, 2017 at 2:39 PM, Michael Brown <mc...@ipxe.org> wrote: >> On 03/03/17 12:37, Ladi Prosek wrote: >>> >>> The goal of this series is to make it possible to use iPXE with security >>> features, such as HTTPS, in enterprise environments where rebuilding >>> from sources is not an option and connecting to external services is not >>> desired. An ideal iPXE binary for this environment: >>> >>> 1) Does not use any cross-cert server by default. It can be configured >>> at runtime but is not required at build time (PATCH 1). >>> >>> 2) Does not contain any trusted certificate fingerprints. They can be >>> configured at runtime but the binary may have nothing embedded in it >>> (PATCH 5). >>> >>> 3) Allows trusted root certificate fingerprints to be changed by trusted >>> images (PATCH 3, 4). >>> >>> 4) Assumes initrd, kernel command line, and images embedded in iPXE to >>> be trusted (PATCH 2). >>> >>> The particular scenario I am interested in is ipxe.lkrn booted locally >>> from ISOLINUX and passed a script as initrd. The script is trusted and >>> should be able to configure crypto as needed before chaining into an >>> HTTPS-downloaded image. Thanks! >> >> >> I agree with the goal. I am not (yet) convinced that >> >> current_image->flags & IMAGE_TRUSTED >> >> is a suitable definition of this goal, since it leaves open the question of >> whether or not an interactive command line is allowed to redefine the root >> of trust. Specifically, with this definition: >> >> - an interactive command line entered via the default Ctrl-B prompt would >> _not_ be allowed to change the root of trust >> >> - an interactive command line entered via an identical-looking Ctrl-B prompt >> generated by an embedded script _would_ be allowed to change the root of >> trust >> >> - an interactive command line entered as a debugging tool from a trusted >> menu script _would_ be allowed to change the root of trust > > Thanks, yes, I see how interactive can be confusing. > >> I wonder if it might be cleaner to either: >> >> - allow for a build in which the root of trust may be changed once (and >> thereafter may not be changed again), or > > This looks like a reasonable option. It's unlikely that the root of > trust needs to be set more than once. > > Would you rather add a new 'set once' flag to the setting > infrastructure or introduce a completely separate command for this? > >> - extend the existing "image trust requirement" concept (as exposed by the >> "imgtrust" command) to include the notion of whether or not the root of >> trust is allowed to be changed. > > That would be fine too. And actually same question as above: > > set --permanent trust 00:01:02:.. > > or > > settrust --permanent 00:01:02:.. > >> Michael
I'd like to restart the discussion. Any objections against the first patch? It should be fairly non-controversial, just adding a graceful handling of empty CROSSCERT. [RESEND PATCH 1/5] [crypto] Fail fast if cross-certificate source is empty For the rest of the proposed changes, can you please answer the questions in my last email? Thanks! Ladi _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
