RFC: Inclusion of Secure Boot Key Manager

[Samuel Mendoza-Jonas]

On Thu, 2017-01-12 at 15:48 -0600, Eric Richter wrote:
> I've been looking into ways to include a secure boot key manager in 
> skiroot, and ran into a few snags in the design. In order to maintain 
> the "trusted" state of the system, shell access should be avoided due to 
> the unrestricted manner of complete shell access. Instead, it would be 
> sensible to limit a user's ability to interact with the keys through a 
> menu. However, implementing this as a menu in Petitboot would then 
> introduce more platform specific code.

Just as an aside, what scenarios are we specifically concerned about when the
user has shell access? (The most obvious one that comes to mind would be
flashing a new PNOR).

Timothy Pearson's separate secure boot work added a mechanism to restrict
shell access which could be adapted here:
http://git.ozlabs.org/?p=petitboot;a=commitdiff;h=f5dab0206a3baca73895a587583ddfa402f8f569

> 
> I've enumerated a few ideas for this, and would like some input on what 
> seems most feasible for this (or alternatively, if I am overthinking this).
> 
> 1. Include key management as a submenu in Petitboot, have the menu make 
> calls to a key manager binary included in skiroot
> 2. Include key management as a pluggable system, and provide a menu that 
> makes abstract calls that each platform can implement differently

I'm not necessarily opposed to #2 and using Petitboot's ability to
differentiate between different platforms.

> 3. Implement a completely separate menu application for key management, 
> and provide a link to it in Petitboot.

But I tend to agree that #3 will probably be the easiest or more adaptable
approach.

Depending on the exact approach is this something that could be handled by the
pb-plugin ABI? Coincidentally I have some in-progress work to make pb-plugins
installable and executable from with Petitboot without having to drop to the
shell to improve UX, perhaps it could suit this too.

> 
> 
> The first option is most likely the easiest, as it only requires adding 
> a menu to Petitboot, however that would be completely dependent on the 
> operation of the key management tool. Thus, it is not particularly 
> useful for other platforms (like x86).
> 
> The second option requires a bit of abstraction between potential secure 
> boot key mechanisms. POWER and x86 both have a similar key hierarchy, so 
> the Petitboot front-end would be identical, but the method for how the 
> keys are manipulated under the hood would need to be implemented per 
> platform (x86 using efivars or similar, POWER via pnor).
> 
> Finally, the third option doesn't particularly involve Petitboot at all, 
> other than launching a different application to handle the keys.
> This way, key management in POWER and x86 (and any other platform) can 
> be done with their own utilities *without* having to drop into an 
> untrusted shell. An alternative option as well, is to provide a list of 
> accepted, signed, or "trusted" applications that can be launched from 
> Petitboot without needing to drop the trust level (for example, 
> diagnostic tools to debug a boot failure).
> 
> 
> Currently, the third option appears to be the strongest, but I would 
> appreciate any feedback/comments on the feasibility (or alternative 
> ideas) before I start development.
> 
> Thanks!
> Eric Richter
> 
> _______________________________________________
> Petitboot mailing list
> Petitboot at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/petitboot