Date: Sun, 9 Apr 2017 12:01:42 -0400 From: Eric McCorkle <eric@metricspace.net> To: "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: <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> In-Reply-To: <20170409155240.GA18363@brick> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4 Content-Type: multipart/mixed; boundary="P2CjpF9BIF78trnltNW12bP2AkfCfbv8U"; protected-headers="v1" From: Eric McCorkle <eric@metricspace.net> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>, freebsd-security@freebsd.org Message-ID: <8a60d967-eb7f-b529-df03-c0bfccbe9747@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> In-Reply-To: <20170409155240.GA18363@brick> --P2CjpF9BIF78trnltNW12bP2AkfCfbv8U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 mo= dule >>>>>> 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 mak= ing >>>>> it load modified 4th files, you can do absolutely anything you want= ; >>>>> AFAIK they have unrestricted access to hardware. So you should pre= ferably >>>>> be able to sign them as well. You _might_ (not sure on this one) a= lso >>>>> want to be able to restrict access to some of the loader configurat= ion >>>>> variables. >>>> >>>> Loader is handled by the UEFI secure boot framework, though the conc= erns >>>> 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. >> >> I explored the idea of wrapped or detached signatures in the previous >> discussion. Envelopes or detached signatures could make sense for the= >> 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 ports >> collection, and so on, whereas signing the executable with an addition= al >> section has no such consequences. >> >> Config files (and the 4th files really are more like config files) hav= e >> a different set of constraints, and detached signatures are probably t= he >> way to go there. So loader should probably support detached PKCS#7 >> signature checks. >=20 > 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 compatibility with any file format that uses a different comment character. It also mandates some kind of ASCII encoding scheme to avoid newlines. If I was going to adopt a solution that broke existing tooling, I'd at least go with a proper envelope scheme. --P2CjpF9BIF78trnltNW12bP2AkfCfbv8U-- --O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWOpa5gAKCRBWwohAqoAE jWZbAP4iE8lRz6j0hwlRq4UEs8FRld4Okk4KzkmhwOJ4Wm8Z7QD+KTupXfPRXknm 6S8BLi6wyH1kgDDmwp8CGw/iQTv66Q8= =EaXS -----END PGP SIGNATURE----- --O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8a60d967-eb7f-b529-df03-c0bfccbe9747>