[ipxe-devel] [RESEND PATCH 0/5] [crypto] Relax root certificate restrictions

[Ladi Prosek]

On Fri, Mar 3, 2017 at 2:39 PM, Michael Brown <mcb30 at 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