Simon J. Gerraty
2017-08-30 21:55:48 UTC
Hi,
Background:
I've been adding what amounts to a mini "verified exec" to the freebsd
loader for use in Junos.
What this means is that the loader verifies the kernel and all the
modules before loading them, and can reject anything for which a
registered fingerprint (eg. sha1 hash) does not match.
This work is probably mainly of interest to folk doing emeded devices
or security appliances etc and can be seen as closing the gap between
the secure BIOS (which verifies initial loader - grub? whatever)
and mac_veriexec which we use in the kernel to control what can run in
userland.
The boot process on Junos is much more complicated - but also more
flexible than stock FreeBSD.
We potentially load lots of "loader.conf" snippets from different
packages which contribute modules that need to be pre-loaded.
Of particular interest, we always provide the kernel with an md_image
for initial rootfs, which means the loader can verify the kernel and
everything it uses before mac_veriexec is initialized.
This obviates the need to touch the kernel at all.
For efficiency and flexibility of signing, we use signed 'manifest'
files to carry the trusted fingerprints.
These manifest files are signed using RSA or ECDSA and an accompanying
X.509 certificate chain, allows one to verify the public key was issued
by a trusted entity.
This approach has proven useful for more than a decade, and allowing the
loader to do the same, was an obvious choice for us.
Which brings me to BearSSL (www.BearSSL.org)
This is a very small library designed to work in embedded environments.
The author gave a talk about it at BSDCan earlier this year
and it is just what I've been looking for for this project.
All the code to do signature verification, fingerprint matching etc,
in fact the entire mini-veriexec for the loader adds only about 80K.
Last I looked at trying to achieve the same using OpenSSL - I gave up at
6M ;-)
The question is what to do - for upstreaming any of this.
Assuming of course anyone is interested in this functionality.
The changes to the loader itself are trivial.
Most of the code is in libve (naming stuff is hard) which handles
fingerprint loading, lookup and of course verifying signatures using
code from; libbearssl - which is just a reachover build of BearSSL.
I have it setup such that BearSSL need not be part of the tree at all so
there is no burning need to import it; lib/libbearssl will simply not
build if ${BEARSSL} isn't defined and pointing to a BearSSL tree.
From an internal paper-work point-of-view, contrib/bearssl is attractive
to me ;-), but it could just as easily be in ports no where at all.
If it were in contrib, then it would be feasible to leverage it for
other uses in the loader that currently use libmd etc for hashing.
Discuss ?
Thanks
--sjg
Background:
I've been adding what amounts to a mini "verified exec" to the freebsd
loader for use in Junos.
What this means is that the loader verifies the kernel and all the
modules before loading them, and can reject anything for which a
registered fingerprint (eg. sha1 hash) does not match.
This work is probably mainly of interest to folk doing emeded devices
or security appliances etc and can be seen as closing the gap between
the secure BIOS (which verifies initial loader - grub? whatever)
and mac_veriexec which we use in the kernel to control what can run in
userland.
The boot process on Junos is much more complicated - but also more
flexible than stock FreeBSD.
We potentially load lots of "loader.conf" snippets from different
packages which contribute modules that need to be pre-loaded.
Of particular interest, we always provide the kernel with an md_image
for initial rootfs, which means the loader can verify the kernel and
everything it uses before mac_veriexec is initialized.
This obviates the need to touch the kernel at all.
For efficiency and flexibility of signing, we use signed 'manifest'
files to carry the trusted fingerprints.
These manifest files are signed using RSA or ECDSA and an accompanying
X.509 certificate chain, allows one to verify the public key was issued
by a trusted entity.
This approach has proven useful for more than a decade, and allowing the
loader to do the same, was an obvious choice for us.
Which brings me to BearSSL (www.BearSSL.org)
This is a very small library designed to work in embedded environments.
The author gave a talk about it at BSDCan earlier this year
and it is just what I've been looking for for this project.
All the code to do signature verification, fingerprint matching etc,
in fact the entire mini-veriexec for the loader adds only about 80K.
Last I looked at trying to achieve the same using OpenSSL - I gave up at
6M ;-)
The question is what to do - for upstreaming any of this.
Assuming of course anyone is interested in this functionality.
The changes to the loader itself are trivial.
Most of the code is in libve (naming stuff is hard) which handles
fingerprint loading, lookup and of course verifying signatures using
code from; libbearssl - which is just a reachover build of BearSSL.
I have it setup such that BearSSL need not be part of the tree at all so
there is no burning need to import it; lib/libbearssl will simply not
build if ${BEARSSL} isn't defined and pointing to a BearSSL tree.
From an internal paper-work point-of-view, contrib/bearssl is attractive
to me ;-), but it could just as easily be in ports no where at all.
If it were in contrib, then it would be feasible to leverage it for
other uses in the loader that currently use libmd etc for hashing.
Discuss ?
Thanks
--sjg