From owner-freebsd-security@freebsd.org Wed Mar 29 13:54:53 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7221AD2387D for ; Wed, 29 Mar 2017 13:54:53 +0000 (UTC) (envelope-from michael@fastmail.ca) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41DBE3472 for ; Wed, 29 Mar 2017 13:54:52 +0000 (UTC) (envelope-from michael@fastmail.ca) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DDFC520ACF; Wed, 29 Mar 2017 09:54:51 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute4.internal (MEProxy); Wed, 29 Mar 2017 09:54:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.ca; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=WkOGLGL+nZBMirnA4sCswCDo3O dO/XX+zQZFU/dwQpQ=; b=F+QyjMpJCSfBzMq+pJp6KV8WXM8V04kPpK0AK5iE45 cgZ8j8uoVEVNTvnU2q7ODx46l278ekC2B7lu4WP5Nu5cZc5A13BnjAn0I7yNyUvq acX/RDGzyPEUeijcYIy8QD1Mgr4PiRdPyUglgFAqY6+Nq8QBB+Vp+4irn5047KNO E= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WkOGLG L+nZBMirnA4sCswCDo3OdO/XX+zQZFU/dwQpQ=; b=YgKQ4I1/+xlls7fZmZIj8n yd6H5zCS80IKnCoxa7VXwhrc/Deg4Y/iQLeQHfoDxcx5EhVhSBdcDxV9TazpmrCs QoCtgJfZNXh1QLiwQAQiULhfznoehGMrwL2oE9fpnDOmymY3Z0e12bGNHEwAzTiQ coqh7OSMbZ1GgQc8kYVHIpMrvalyfvdD8vZUsnlIlfLbrdGWexfHij7Dp3mXKko+ FR06wg19YlaZz5+U9M9yHLb9/lFjgMLHjh1SAL7zooCge4EH8cJeohy9Xt63fWaH oSsd5/SsPcG2GnEikPsFkdciOlGm99jGBcMkmq7Qan7ppxYt8ZdLK70a9jV/TMyQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5204BAB41; Wed, 29 Mar 2017 09:54:51 -0400 (EDT) Message-Id: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> From: Michael Richards To: freebsd-security@freebsd.org Cc: eric@metricspace.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-96d0475f Subject: Re: Proposal for a design for signed kernel/modules/etc In-Reply-To: Date: Wed, 29 Mar 2017 06:54:51 -0700 References: X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 13:54:53 -0000 > 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