Date: Wed, 29 Mar 2017 06:54:51 -0700 From: Michael Richards <michael@fastmail.ca> To: freebsd-security@freebsd.org Cc: eric@metricspace.net Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> In-Reply-To: <mailman.52.1490702401.61780.freebsd-security@freebsd.org> References: <mailman.52.1490702401.61780.freebsd-security@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) Be able to check for a correct cryptographic signature for any kernel > or modules loaded at boot time for some platforms (EFI at a minimum). I think it would be valid to have a boot from write protected device (USB key) that does the initial kernel check and load and maybe stores the keychain. > 7) The design must allow for the adoption of new ciphers (there is an > inevitable shift to post-quantum ciphers coming in the near future) Despite peoples' dislike of paying for keys, there is already a system in place for vendors to pay for authenticode keys. It would be nice if this were also supported. This way, my company can maintain the authenticode keys we already pay for and if a FreeBSD binary were produced we could use the existing infrastructure to sign them without the need to introduce yet another key to manage. > In this proposal, cryptographic signatures would be stored in a > .signature (or .sig) section. This section would contain an array of > signature constructs: one for each loadable segment in the ELF file. > Signatures are computed for the contents of the segment's file data (ie. > the data from p_offset to p_filesz, for the corresponding program header > entry) along with all data from its program header entry except for > p_offset and p_filesz. This scheme allows the actual data to be moved > around in the file, so long as it (or the relevant program header data) > isn't modified. I think it will be important to consider a backward and forward compatible format for your sections. XML is too big to audit a parser, but something simple and parseable with a version number and such would be good. Suppose a security flaw is found, then you should be able to configure the acceptable signing scheme/version. I also think the scheme here is a bit complicated. Once an executable or library is produced and installed on my machine I don't know that there is or should be any legitimate need to modify or re-order the contents. Just make the file and sign it. If it's modified, I want to know! The simpler the solution, the easier to implement, test and audit. As an extension to this idea, it would be interesting if a database of exploitable system .exe and libraries were maintained. It would be handy as an admin to have an immediate report that library XYZ on your system is exploitable and needs your attention. -Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1490795691.3691150.927389880.305FD2A4>