RFC: Inclusion of Secure Boot Key Manager
Eric Richter
erichte at linux.vnet.ibm.com
Fri Jan 13 08:48:05 AEDT 2017
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.
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
3. Implement a completely separate menu application for key management,
and provide a link to it in Petitboot.
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
More information about the Petitboot
mailing list