Edward Tomasz Napierała
2017-Apr-08 11:52 UTC
Proposal for a design for signed kernel/modules/etc
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.
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/D8575Is 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>