From owner-freebsd-hackers@freebsd.org Sun Apr 9 16:50:37 2017 Return-Path: Delivered-To: freebsd-hackers@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 AE10CD365D0 for ; Sun, 9 Apr 2017 16:50:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A811789 for ; Sun, 9 Apr 2017 16:50:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id a103so7153059ioj.1 for ; Sun, 09 Apr 2017 09:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=uq4N62VcObOpr6hm1+yt24jW5Lh4EG5i+bJ9+JSrzn8=; b=Yy8+Q7CiyFdr9jOo5b0lcI6gWUdlae3qFXQgXDEpw7wne6mSQPVMBpmATDg579XYDu 5S6axvlm+TyNFVZhLr/N0pmR0UYF3DQHgYy33nW9Wh6fQ5Htwhw8oBm3FClQPMAs74R3 BQeK2ADJtQr2PHMkndIFAg3xO1zP/H5l7fGcWjRdDRbsSl6HVeQIOI3f8JygKMCRTwGV 3M5PjZ8itgU0ufL7UvkEVFWaXuM4yxl71UZR5AzGElQlNbhfZcqglKTapItY31miP7+L DbFugGr1IfUcVj8JBBNeRqR586HSx90LQvbHWbktfoY0IUmya4u2x1uekENOhY9BF2Nh Wnaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=uq4N62VcObOpr6hm1+yt24jW5Lh4EG5i+bJ9+JSrzn8=; b=OTYeGrhtkvV+TlQnLR3Ra0bPcXLgCgBU7vBCvOds7jsCErDahY/ELpVrvziueaKQ4v t9jE2n1PsjtAWpGZxkCjTR+10LAn1ZwLMuVATkZVwgUfO1Vnyj7rkAq9fyiVjLDSVPYx EKR5qGnxODX6/p6x6eVIPdVV8F5cI7dfn5NZwWQ8PVK0dKs1gfDfCWqi8zYIeNtPV6a7 w19oZhq9Yse9FDEDevkj1inoSGZLaL9h6kBX3cG77k5RkteCoqqYAXV1gIqND6WXrvWY VRDGb/Qded5Sx+M6o9pCIorw7P1DvFETZY3Pum7LinwqWfqRxe71z7XItauN5YAVXRCl 6xfg== X-Gm-Message-State: AN3rC/53UZlGsKPu34znOT5JiWojidwCmIiDaOmqzxx1fQPpXERBlMnkIJU1Jsk0YuX7lk8ZfgehIWhk1JgNkg== X-Received: by 10.107.198.137 with SMTP id w131mr2892855iof.19.1491756636689; Sun, 09 Apr 2017 09:50:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Sun, 9 Apr 2017 09:50:36 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::b517] In-Reply-To: <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> 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> From: Warner Losh Date: Sun, 9 Apr 2017 10:50:36 -0600 X-Google-Sender-Auth: zkX6U72fUJc7oD084joHMA5XRig Message-ID: Subject: Re: Proposal for a design for signed kernel/modules/etc To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 16:50:37 -0000 On Sun, Apr 9, 2017 at 10:01 AM, Eric McCorkle wrote= : > 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 mod= ule >>>>>>> loading, both at boot- and runtime (with the possibility open for s= igned >>>>>>> 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 maki= ng >>>>>> it load modified 4th files, you can do absolutely anything you want; >>>>>> AFAIK they have unrestricted access to hardware. So you should pref= erably >>>>>> be able to sign them as well. You _might_ (not sure on this one) al= so >>>>>> want to be able to restrict access to some of the loader configurati= on >>>>>> variables. >>>>> >>>>> Loader is handled by the UEFI secure boot framework, though the conce= rns >>>>> about the 4th code are still valid. In a secure system, you'd want t= o >>>>> do something about that, but the concerns are different enough (and i= t'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 additiona= l >>> section has no such consequences. >>> >>> Config files (and the 4th files really are more like config files) have >>> a different set of constraints, and detached signatures are probably th= e >>> 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 compatibility > with any file format that uses a different comment character. It also > mandates some kind of ASCII encoding scheme to avoid newlines. 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. > If I was going to adopt a solution that broke existing tooling, I'd at > least go with a proper envelope scheme. That would be preferable. 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). Warner