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

[Ladi Prosek]

On Fri, Mar 3, 2017 at 5:20 PM, Ladi Prosek <lprosek at redhat.com> wrote:
> 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

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