From owner-freebsd-security@freebsd.org Sat Apr 8 11:39:30 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 98862D34BFE; Sat, 8 Apr 2017 11:39:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 2FAED1DC; Sat, 8 Apr 2017 11:39:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id d79so2165782wmi.2; Sat, 08 Apr 2017 04:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=i2+i21H7oFNUJzp/Dy4+LY4YaX0mUfWAahwmt8ZUCtM=; b=cowhy8IOu/8d83ZOu2YtmHrP0bkr+oaQ6NL7/0mZT66lbnkS7q0i3sEKn9lMR+f5w7 WJN2YzqYBX2Oyi2alNX0fJ47K0zIBGS4L+YbURM4eiAdvlpuOLwK05UozAKJgZt4ycW3 BBqAseuHUuRaJuCIEpaVCdyGfa5VY6IXG7YeeEx2djmZIIwijY0CvanZy4nlEwy4eSms 2qs4OTZiNXfYwYVqgQebZ3wK9hQpfZm7yczH5eNpE21RBLQlQUUuBJelWT/c2JPC1WXL Xon1J+lRiFn8jkQIXPu26AO8AvjB5fByzHDdMHo/9nPmc+7AlfA9u849vEef4hwW/ZKV gKyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=i2+i21H7oFNUJzp/Dy4+LY4YaX0mUfWAahwmt8ZUCtM=; b=NbG9ydy+jPLbtffeEEck4YeKP8ToE4Hr8kpzeAayYOz3nLuv1jeAwgsT0gl3mrC5rX T5LFHyeTW6bnKAo++fLGBjTxRVKNzAseYrLogfLFdpPqDnXtKsiueMuBOwpkrGuNcD2T X/BOAag7+DrK9p5VzH7WSb2Ul8utLdbiNXMZHatosI3iee/bzXN11X/3rrI3C1Jfw/bQ gzmAoeEnovgCM6p6+fbWWFi/jjFKo3DOAwhp2JwSPsNXFYIdQ9mXVAax2Jska3+5272z /Ttqb/afRvo/8G8QdsgXjpY2sNsvznE9/sjJ3bNrATVkozVjP+/kXzhse2HstJSnLRoE AKdw== X-Gm-Message-State: AN3rC/4Yl1B+6t9Cb9KdFPYofePyzfTnA7tkTL4VEuKFBdrt/K6fK3BHTIeeolvbxcS7Lg== X-Received: by 10.28.186.3 with SMTP id k3mr1669973wmf.74.1491651568551; Sat, 08 Apr 2017 04:39:28 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id u36sm5399485wrc.20.2017.04.08.04.39.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 04:39:28 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 8 Apr 2017 12:11:44 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <20170408111144.GC14604@brick> Mail-Followup-To: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> User-Agent: Mutt/1.8.0 (2017-02-23) X-Mailman-Approved-At: Sat, 08 Apr 2017 11:40:59 +0000 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: Sat, 08 Apr 2017 11:39:30 -0000 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 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 making it load modified 4th files, you can do absolutely anything you want; AFAIK they have unrestricted access to hardware. So you should preferably 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 configuration variables. Second - given OpenSSL track record, moving signature verification and the x.509 stuff into the kernel (to verify userland) and loader (to verify the kernel and modules)... well, it just doesn't seem to be a good idea. Also: do you know about veriexec? https://reviews.freebsd.org/D8575 From owner-freebsd-security@freebsd.org Sat Apr 8 12:03:46 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 ED0A0D34E54; Sat, 8 Apr 2017 12:03:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id AA9D9861; Sat, 8 Apr 2017 12:03:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.198] (unknown [172.16.0.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id F339316E6; Sat, 8 Apr 2017 12:03:45 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> From: Eric McCorkle Message-ID: <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> Date: Sat, 8 Apr 2017 08:03:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170408111144.GC14604@brick> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qBnpgPE5iiBH2Q2URRsv4WA5VCo3qAhHN" 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: Sat, 08 Apr 2017 12:03:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qBnpgPE5iiBH2Q2URRsv4WA5VCo3qAhHN Content-Type: multipart/mixed; boundary="KQKRohTHn9LW4Ce3DD5LtEgm1pORiCnQU"; protected-headers="v1" From: Eric McCorkle To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> In-Reply-To: <20170408111144.GC14604@brick> --KQKRohTHn9LW4Ce3DD5LtEgm1pORiCnQU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 for sign= ed >> executables and libraries if someone wanted to go that route). I'm >> interested in feedback on the idea before I start actually writing cod= e >> for it. >=20 > I see two potential problems with this. >=20 > First, our current loader(8) depends heavily on Forth code. By making > it load modified 4th files, you can do absolutely anything you want; > AFAIK they have unrestricted access to hardware. So you should prefera= bly > 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 configuration > variables. Loader is handled by the UEFI secure boot framework, though the concerns 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. > Second - given OpenSSL track record, moving signature verification > and the x.509 stuff into the kernel (to verify userland) and loader > (to verify the kernel and modules)... well, it just doesn't seem > to be a good idea. Integrating all of OpenSSL would be massively overkill. All you need is RSA/Ed25519 signature verification and parsing a subset of PKCS#7. My thoughts here are to grab the RSA/Ed25519 implementations from libsodium and just write a minimal PKCS#7 parser. > Also: do you know about veriexec? >=20 > https://reviews.freebsd.org/D8575 Is there some documentation of this other than a code review? --KQKRohTHn9LW4Ce3DD5LtEgm1pORiCnQU-- --qBnpgPE5iiBH2Q2URRsv4WA5VCo3qAhHN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljo0ZwACgkQ1w0wQIFc o2eLWhAAyJJZKs/vQzV+/CLs2gm+xA4F+kkYFnTiuPgzanOnE0N24DBfQ01ODIwI bV9M+yXxJMcmNbLsmjQs3GQjrXF9eclobs2q9juhjm3hcs0XxV0i6j00v0TtIHxW xCyqEt506u6FsAApasBj6s+cvDL/KeSnXIZTB8VeMriXV+SRK2yl6rPRch51mjvC Ph88Rvxe9i2G49DqRigpsbMYgvd/Q/60cPdciLLq2KJYbgMKJY7nejZJF3A0L5bS 9S5dbkl9kmMtNBknOeQZxF9JcuIesymrz0WOjtPpB837lDjOtLhrtrbCcvZ5lYzo Uw6qLS5junOPNQi+xsSW14EnxgIMIMMvd9WqBRh0Jl+mzHiZDUY83SnvwEu48Nzp 5FBbhbv4cH5wrXpHzjAFt2eKRdnksSFG2xGGuRXAIf81xzNmZGfsM1+Q6ms/sBu9 BNxdgIoZdzcawA+ItJVplrMXTTfjJ94cwUPMUXm1F1MJNvS8c4wZr9Velvq+gF4b 9dsoN6/JlmjKkbZPpot+UvVkMUtGOFUBQf/Gcu+L3cM6NTIDLzSpgoVRzwbdMm/h AIlsFF3r664qntaT1cgOQcw5IN9k3rVXmhCm31XFoZzqFQdsL+AcrRSc0UiKrk29 OozqrwCyOX0brwQQixBLERu86nzacsQl3/8L1EMFY7NiFQvvqh0= =jbMq -----END PGP SIGNATURE----- --qBnpgPE5iiBH2Q2URRsv4WA5VCo3qAhHN-- From owner-freebsd-security@freebsd.org Sat Apr 8 12:20:09 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 22389D33469; Sat, 8 Apr 2017 12:20:09 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 AE290FB9; Sat, 8 Apr 2017 12:20:08 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id o21so94984618wrb.2; Sat, 08 Apr 2017 05:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=XobHHXa5gBlO4FgGmMJm1dVEnAWAGgT6oEn2g9zMgHQ=; b=q+dxSTBUltZc6KrMFf7VG4rlbkMT4j+M/0rjN9jRMxpQTy9WGxOJFTWYfklePdWYgH E2fy4LXY7cf8v+tm80msWyKhTODP4J+5UD+J+wLgm6ednjMrF0su+rhR8ApQFohHfwan FgIOG2bvcay416ZvCT73+BtUQgKqxo0ctOsnWtuTQeVKmrVzFzyq+vNlGpnrqe3lyvUy ORUqWYE6/zIK14Kjce2ZT1rt4netXylNAX03+f4I1r5b1aKsQ0gfyxLua1tHQ+gVpix9 BWrUy30rZG8IZV3iTFe3JNe+37/yd4yzs3hKoxOuaJDILNHTc7pfjcY0aD/FWSMJMiU1 yiOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=XobHHXa5gBlO4FgGmMJm1dVEnAWAGgT6oEn2g9zMgHQ=; b=Rxz/LCb1rFDNsM4JAKWKbHhrmFFNClqMgdlf8USq2nobBakBQmGNQ/fsQOZlkzh4wy SKj/nvMlGATeH8dVZaGtJVxomdBHvbverRlcW8ua6hmyEf+OV/Oizp/Z+RCn43WA17no xWZEqyLW3XTpGQbCRxxkJEOsdVl1qU//1BVgM/ja9d1bgAJLKMzzCel2q0dCWH6CVL2X wmaLnExo8QqvTZGCbuv15qYB5TgRFBr3Qcjegi5px7A+gpxsUV6nEgC9OEf54c+5D58R ckLdzrL5e2eqmUqdlJleh3l9iK0DiGzZ2UrXApalYnS6mE0aU7/lzhoS8s4GhLJjOOvn 73Fw== X-Gm-Message-State: AFeK/H3/QINj4ZaLKZqjpRJgFhtwyHnz5R1wUi3TIDTDYgxTN1OmnrdBp7nBwinzmrk/ZA== X-Received: by 10.223.175.207 with SMTP id y15mr37082764wrd.63.1491654005920; Sat, 08 Apr 2017 05:20:05 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id 51sm9707510wrx.38.2017.04.08.05.20.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 05:20:05 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 8 Apr 2017 12:52:22 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <20170408115222.GA64207@brick> Mail-Followup-To: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> User-Agent: Mutt/1.8.0 (2017-02-23) X-Mailman-Approved-At: Sat, 08 Apr 2017 12:51:31 +0000 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: Sat, 08 Apr 2017 12:20:09 -0000 On 0408T0803, Eric McCorkle wrote: > On 04/08/2017 07:11, Edward Tomasz Napierała 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 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 making > > it load modified 4th files, you can do absolutely anything you want; > > AFAIK they have unrestricted access to hardware. So you should preferably > > 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 configuration > > variables. > > Loader is handled by the UEFI secure boot framework, though the concerns > 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. > > Second - given OpenSSL track record, moving signature verification > > and the x.509 stuff into the kernel (to verify userland) and loader > > (to verify the kernel and modules)... well, it just doesn't seem > > to be a good idea. > > Integrating all of OpenSSL would be massively overkill. All you need is > RSA/Ed25519 signature verification and parsing a subset of PKCS#7. > > My thoughts here are to grab the RSA/Ed25519 implementations from > libsodium and just write a minimal PKCS#7 parser. Ok, that seems to be a reasonable idea. > > Also: do you know about veriexec? > > > > https://reviews.freebsd.org/D8575 > > Is there some documentation of this other than a code review? Not sure; it might be best to just ask the author. Note that there are some manual pages in there, and also that it's not a single review - follow the chain of "Depends on", there's a lot of stuff there.