RFC: Inclusion of Secure Boot Key Manager

[Samuel Mendoza-Jonas]

On Thu, 2017-01-12 at 18:52 -0600, Eric Richter wrote:
> 
> On 01/12/2017 05:22 PM, Samuel Mendoza-Jonas wrote:
> > 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
> > 
> 
> Ideally, we would like to include these restrictions as well, hence why 
> having the ability to manage keys within the menu would be beneficial.
> 
> > > 
> > > 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.
> 
> It's not the worst approach, but I did feel it was a bit out of scope 
> and prone to edge cases.
> 
> > 
> > > 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.
> > 
> 
> I'm not familiar with the ABI offhand, is there some documentation or 
> particular source file I can read to fill myself in?

I still need to get around to writing some actual documentation for this, but
the pb-plugin script is fairly self-expanatory:
http://git.ozlabs.org/?p=petitboot;a=blob;f=utils/pb-plugin

Mainly aimed at stuff like RAID utilities that can't be packaged up in Skiroot,
it allows a utility and it's dependencies to be downloaded and installed into a
chroot that Petitboot can then run.

> 
> Currently, someone on my team is/will be working the API for working 
> with the keys. Then, using that API, provide a series of tools which the 
> menu will execute. If this sounds like it could fit using pb-plugin, 
> then that probably would be the best way to handle this.

Of course if the utilities can fit into Skiroot then we can just include them
in the zImage and set support for them at compile time, the Petitboot-side work
I mentioned before doesn't explicitly depend on the pb-plugin format.

> 
> Thanks,
> Eric Richter
>