Date: Sun, 9 Apr 2017 13:17:26 -0400 From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, freebsd-security@freebsd.org Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <082223a0-1768-f5f0-9f4a-2e9fd45716c7@metricspace.net> In-Reply-To: <CANCZdfpibssSCbqcRqDEZeoqLEyLwJMo-dU4ZKhMnH7ceYps_A@mail.gmail.com> References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> <CANCZdfpibssSCbqcRqDEZeoqLEyLwJMo-dU4ZKhMnH7ceYps_A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe Content-Type: multipart/mixed; boundary="CL7dlJ1GfWJTi96v7o8i4fBVIpSo8E8P3"; protected-headers="v1" From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, freebsd-security@freebsd.org Message-ID: <082223a0-1768-f5f0-9f4a-2e9fd45716c7@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> <CANCZdfpibssSCbqcRqDEZeoqLEyLwJMo-dU4ZKhMnH7ceYps_A@mail.gmail.com> In-Reply-To: <CANCZdfpibssSCbqcRqDEZeoqLEyLwJMo-dU4ZKhMnH7ceYps_A@mail.gmail.com> --CL7dlJ1GfWJTi96v7o8i4fBVIpSo8E8P3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/09/2017 12:50, Warner Losh wrote: > On Sun, Apr 9, 2017 at 10:01 AM, Eric McCorkle <eric@metricspace.net> w= rote: >> On 04/09/2017 11:52, Edward Tomasz Napiera=C5=82a wrote: >>> On 0409T1040, Eric McCorkle wrote: >>>> On 04/08/2017 07:52, Edward Tomasz Napiera=C5=82a wrote: >>>>> On 0408T0803, Eric McCorkle wrote: >>>>>> On 04/08/2017 07:11, Edward Tomasz Napiera=C5=82a 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 fo= r signed >>>>>>>> executables and libraries if someone wanted to go that route). = I'm >>>>>>>> interested in feedback on the idea before I start actually writi= ng code >>>>>>>> for it. >>>>>>> >>>>>>> I see two potential problems with this. >>>>>>> >>>>>>> First, our current loader(8) depends heavily on Forth code. By m= aking >>>>>>> it load modified 4th files, you can do absolutely anything you wa= nt; >>>>>>> AFAIK they have unrestricted access to hardware. So you should p= referably >>>>>>> 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 configur= ation >>>>>>> variables. >>>>>> >>>>>> Loader is handled by the UEFI secure boot framework, though the co= ncerns >>>>>> about the 4th code are still valid. In a secure system, you'd wan= t to >>>>>> do something about that, but the concerns are different enough (an= d 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. >>>> >>>> I explored the idea of wrapped or detached signatures in the previou= s >>>> discussion. Envelopes or detached signatures could make sense for t= he >>>> 4th files. It's a small, obscure set of code that probably isn't >>>> changed very often. >>>> >>>> Envelopes or detached signatures for kernel modules and especially >>>> signed executables and libraries both have extensive, far-reaching >>>> consequences for system administration, packaging, tooling, the port= s >>>> collection, and so on, whereas signing the executable with an additi= onal >>>> section has no such consequences. >>>> >>>> Config files (and the 4th files really are more like config files) h= ave >>>> a different set of constraints, and detached signatures are probably= the >>>> way to go there. So loader should probably support detached PKCS#7 >>>> signature checks. >>> >>> The third way that might be worth considering would be to just append= >>> the signature. This would work for both 4th (if you prepend it with >>> whatever is the 4th comment character) and ELF, without the need for >>> changing or extending either format. >> >> No, that won't work at all. That's going to break the tooling for ELF= >> files as well as applications that use them, and it won't work for any= >> configuration file aside from loader.4th It wouldn't even work for >> boot.conf, for example. >> >> More generally, that's basing an entire standard off a dead language >> that's used in only one place, and in a way the precludes compatibilit= y >> with any file format that uses a different comment character. It also= >> mandates some kind of ASCII encoding scheme to avoid newlines. >=20 > You don't need to avoid new lines with 4th. It doesn't even need to be > an ASCII encoding scheme, unless you are doing something crazy like > trying to push the signature through the 4th parser, which is nuts. > Forth can read binary files just fine. But I think arguing over the > 4th stuff is a distraction, dee below. >=20 >> If I was going to adopt a solution that broke existing tooling, I'd at= >> least go with a proper envelope scheme. >=20 > That would be preferable. >=20 > But why the either-or dichotomy? Seems like you're looking at the > problem wrong if you are arguing about 4th code. You should be > thinking more in terms of, at most, a couple of 4th words that can > implement this stuff (so the loader could show that the kernel is > signed and valid vs is not signed vs is signed, but the signature is > bogus). 99% of the functionality should be in C, and should be > sharable between the loader, the kernel and whatever else may wish to > verify signatures before loading. It would also allow the same > functionality to be pushed into the on-again-off-again LUA boot > project (which seems to have momentum this time). >=20 I'm not following what you're saying. I don't think anyone was suggesting doing signature *verification* in 4th (at least I hope not!). The issue is about the format of the signatures. Basically, the crux of my proposal is about using an ELF section to store signatures, which has immediate use for kernel module loading as well as in the boot loader for the same purpose. Now, the boot programs, loader, and perhaps the kernel too all load various additional config files (boot.conf, loader.4th, loader.conf, etc). These do also need to be signed, so there needs to be a solution for this as well. There's significant advantages to the ELF .sign section, and all the alternatives have serious disadvantages. For these reasons, I'm pretty set on the .sign section. With the config files (which includes the 4th code), you don't have a file format that transparently supports additional metadata (like ELF does). So you have a choice between storing detached signatures in an external file (the way GRUB does) or using an envelope format. Of the two, the envelope is preferable, I think, though it should probably have a different name (ex: loader.4th.pk7, loader.conf.pk7) and be understood to contain an envelope, not a raw config file. The implementation of all this would be in C, of course. The verification stuff would be compiled in to loader and kernel. The elf-signing would be done by a command-line utility (which I've half-written at this point). Ideally, the signing of config files would be doable with the standard openssl command-line. --CL7dlJ1GfWJTi96v7o8i4fBVIpSo8E8P3-- --MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWOpspgAKCRBWwohAqoAE jQ38AQCBS/XagV7XTbcddwhcVSvvwPw1iQKYnMYAUUumSSJ9ZQD/ahJsW5QVbf7R d8z+nk1a4SUI98zbv4crR0O+pXjHSgE= =BuYb -----END PGP SIGNATURE----- --MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?082223a0-1768-f5f0-9f4a-2e9fd45716c7>