Re: Proposal for a design for signed kernel/modules/etc
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. 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. Also: do you know about veriexec? https://reviews.freebsd.org/D8575 ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Proposal for a design for signed kernel/modules/etc
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? signature.asc Description: OpenPGP digital signature
Re: 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. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
