Proposal for a design for signed kernel/modules/etc

[Eric McCorkle]

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.

> 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.

> Also: do you know about veriexec?
> 
> https://reviews.freebsd.org/D8575

Is there some documentation of this other than a code review?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20170408/78a26da6/attachment.sig>