Proposal for a design for signed kernel/modules/etc

[Edward Tomasz Napierała]

On 0408T0803, Eric McCorkle wrote:
> On 04/08/2017 07:11, Edward Tomasz Napierała wrote:
> > On 0327T1354, Eric McCorkle wrote:
> >> Hello everyone,
> >>
> >> The following is a design proposal for signed kernel and kernel module
> >> loading, both at boot- and runtime (with the possibility open for signed
> >> executables and libraries if someone wanted to go that route).  I'm
> >> interested in feedback on the idea before I start actually writing code
> >> for it.
> > 
> > I see two potential problems with this.
> > 
> > First, our current loader(8) depends heavily on Forth code.  By making
> > it load modified 4th files, you can do absolutely anything you want;
> > AFAIK they have unrestricted access to hardware.  So you should preferably
> > be able to sign them as well.  You _might_ (not sure on this one) also
> > want to be able to restrict access to some of the loader configuration
> > variables.
> 
> Loader is handled by the UEFI secure boot framework, though the concerns
> about the 4th code are still valid.  In a secure system, you'd want to
> do something about that, but the concerns are different enough (and it's
> isolated enough) that it could be done separately.

Unless the way to address those ends up being a signature mechanism
that doesn't depend on the format of the files being signed.

> > Second - given OpenSSL track record, moving signature verification
> > and the x.509 stuff into the kernel (to verify userland) and loader
> > (to verify the kernel and modules)... well, it just doesn't seem
> > to be a good idea.
> 
> Integrating all of OpenSSL would be massively overkill.  All you need is
> RSA/Ed25519 signature verification and parsing a subset of PKCS#7.
> 
> My thoughts here are to grab the RSA/Ed25519 implementations from
> libsodium and just write a minimal PKCS#7 parser.

Ok, that seems to be a reasonable idea.

> > Also: do you know about veriexec?
> > 
> > https://reviews.freebsd.org/D8575
> 
> Is there some documentation of this other than a code review?

Not sure; it might be best to just ask the author.  Note that
there are some manual pages in there, and also that it's not
a single review - follow the chain of "Depends on", there's
a lot of stuff there.