Date: Wed, 30 Aug 2017 20:40:50 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Daniel Eischen <deischen@freebsd.org> Cc: Ian Lepore <ian@freebsd.org>, <freebsd-arch@freebsd.org>, <sjg@juniper.net> Subject: Re: Import BearSSL ? (Adding verification to loader) Message-ID: <47823.1504150850@kaos.jnpr.net> In-Reply-To: <Pine.GSO.4.64.1708302116090.22940@sea.ntplx.net> References: <44449.1497382261@kaos.jnpr.net> <CAPyFy2BEhPEsFJNj2Gfieb%2BDJ-O9nWR6%2Bwpu-5Ahfia69ohfcQ@mail.gmail.com> <24256.1504130148@kaos.jnpr.net> <1504132983.56799.90.camel@freebsd.org> <Pine.GSO.4.64.1708302116090.22940@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen <deischen@freebsd.org> wrote: > >> 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. > [ ... ] > > > > We need this exact feature (verification of kernel and modules) for an > > upcoming product at work. =C2=A0Including the library code in contrib > > certainly sounds attractive to me, too. > > > > I wouldn't be surprised if interest in this goes beyond those of us > > building embedded appliances. >=20 > Indeed, why couldn't it be enabled by default for FreeBSD.org > packaged distribs? Or am I jumping the gun by a few years? The problem with that, boils down to key management. As an embeded device vendor we totally controll the "trust anchors" and the keys used to sign things. And absent the signing, this is all pretty pointless. My loader for example has 3 Juniper root CA certs in its trust store, which it can use to verify any signature we have generated over the last 10+ years. But it will not accept anything signed by anyone else. That's perfect for an embedded device, not not exactly useful for a stock system. That's why I said this is all mostly likely of interest to embedded vendors - since the generic case is much harder ;-) Now, there is absolutely nothing to stop anyone/everyone doing as we did, and setting up their own X.509 hierarchy, and the signing server we use (freely available from crufty.net) helps a lot with keeping private keys private even in a company with 1000's of people signing stuff. And perhaps FreeBSD.org could sign releases with their own keys. But if you want to build your own modules you need a way to sign them such that your loader will accept them. For something like the loader, an embedded trust-store is a must IMO. But there's no way you could classify this as a zero effort thing. Still, with all that said, I currently have the loader defaulting to a "best effort" mode - where it will attempt to verify everything, but won't get upset if there is no fingerprint for some file - it will tell you (unless it was loader.conf - which is more or less expected to be mutable), though it will not accept a fingerprint miss-match. This lets me experiment with various platforms etc without bricking lots of boxes (makes the test folk unhappy). So you can boot using a verifying loader without everything signed just fine. The behavior is of course tunable from "off", to "strict". --sjg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47823.1504150850>