From owner-freebsd-security@freebsd.org Mon Mar 27 17: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 F0EE8D2007F; Mon, 27 Mar 2017 17:54:53 +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 A7E3017D; Mon, 27 Mar 2017 17:54:53 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (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 AA70E1658; Mon, 27 Mar 2017 17:54:52 +0000 (UTC) To: "freebsd-hackers@freebsd.org" Cc: freebsd-security@freebsd.org From: Eric McCorkle Subject: Proposal for a design for signed kernel/modules/etc Message-ID: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> Date: Mon, 27 Mar 2017 13:54:44 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5tJFchSClLXPlLXBTeF3xliHxegxS2CGS" 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: Mon, 27 Mar 2017 17:54:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5tJFchSClLXPlLXBTeF3xliHxegxS2CGS Content-Type: multipart/mixed; boundary="VfKDQGqN42otawkWgJ1TC8hPFp8JNnhaw"; protected-headers="v1" From: Eric McCorkle To: "freebsd-hackers@freebsd.org" Cc: freebsd-security@freebsd.org Message-ID: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> Subject: Proposal for a design for signed kernel/modules/etc --VfKDQGqN42otawkWgJ1TC8hPFp8JNnhaw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. =3D=3D Goals =3D=3D 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). 2) Be able to check for a correct cryptographic signature for any kernel module loaded during normal operations (whether or not to do this could be controlled by a sysctl, securelevel, or some similar mechanism) 3) Work with what's in base already and minimize new additions (ideally, just a small utility to sign executables) 4) Minimize administrative overhead and ideally, require no changes at all to maintain signed kernel/modules 5) Have a clear path for supporting signed executables/libraries (I'm not planning on pursuing this, but it's worth considering that someone might want to) 6) The design *MUST* support the case where a system builds locally and uses its own key(s) for signing kernels and modules (and anything else) and *MUST* allow the administrator complete control over which key(s) are valid for a given system (ie. no "master keys" controlled by central organizations) 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) =3D=3D Non-Goals =3D=3D * Hardware/firmware-based attacks are considered out-of-scope (there is no viable method for defending against them at the OS level) * Boot platforms that don't provide their own signature-checking framework up to loader/kernel can't be properly secured, and are considered out-of-scope * Boot platforms that impose size restrictions prohibiting incorporation of RSA and ED25519 crypto code (ex. i386 BIOS) are considered out-of-scop= e * GRUB support is desirable, however it is not necessary to support GRUB out-of-the-box (meaning a design requiring reasonable modifications to GRUB is acceptable). * I am not aiming to support signed executables/libraries now, only to avoid shutting the door on them. =3D=3D Existing Solution(s) =3D=3D EFI has a decent design with regard to key management (platform key, which signs system keys, which sign the actual loader); however, its cipher suite is sorely lacking (many broken hashes and weak ciphers, RSA 2048 being the "strongest", no ECC). It also only works with the COFF format, and is only available at boot time. However, it does provide a chain of custody up to loader (to the extent that anyone trusts closed-source firmware blobs, SHA1, and 512-2048 bit RSA keys...) Many implementations also have master keys "baked in" that would allow anything signed by random third parties (Microsoft) to boot regardless of local configurations, or they don't provide any sort of control over (or even access to) the keys at all. EFI obviously isn't viable beyond boot time, and misses most of the goals even there. Its key management hierarchy is an overall good design, however. GRUB currently supports signature checking. It can be configured to require signatures for any of its own modules as well as any kernel or modules that it loads. These signatures are stored *outside* the executable/library, in a file with an added .sig extension. The format is that of an external signature for the entire ELF file as produced by the gnupg program. Linux (I believe) also supports signature checking for modules using the same convention. While functional, this design doesn't meet the goals I outlined: * It relies on the gnupg framework, which is not part of FreeBSD base, and adding it would be a chore (and would end up duplicating a lot of functionality provided by OpenSSL) * It stores the signature separate from the file, which leads to x2 the number of files, would require modifying existing scripts, and complicates administrative tasks. It also leads to failure modes like stale signatures. * There are potential legitimate modifications to non-code parts of an ELF file (such as the .comment section or other similar sections) that would require re-signing the entire file. * The previous two problems really start to look bad when you consider signed executables and libraries, possibly with third-party build/install scripts... * Finally, the gnupg signature format doesn't actually seem to be documented anywhere, or at least not anywhere that doesn't require a lot of digging... An alternate solution, which I believe is used in some places is to wrap the entire executable in a PGP envelope-like format. This solves the issue of an external signature file, but would require extensive modification to the ELF parsing code, let alone the binutils programs that read/modify ELF files. This solution also isn't backwards-compatible at all. Old loaders/kernels will choke on the signed libraries. =3D=3D Proposal=3D=3D My proposal is to store cryptographic signatures within the ELF files themselves in a non-loadable section (similar to the .comment section). As background, the ELF file format has a number of different section types, only some of which comprise the program/library/module's runtime state. The ELF specification and tools provide some "standard" sections with defined meanings, but nothing stops anyone from adding their own sections. The ELF file format is quite flexible, and it is not difficult to add custom metadata to an ELF file. [0] In this proposal, cryptographic signatures would be stored in a =2Esignature (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. The exact format of this data can be discussed, but a design where the signature array corresponds to the program header array seems quite reasonable. The format of the signatures themselves should be something from a well-defined standard, reasonably extensible, and supported by tools in base. =3D=3D Summary of Changes =3D=3D The following changes would be required: 1) Add a userland utility for signing ELF files (call it "signelf"). This would be a pretty straightforward application of OpenSSL and libelf.= 2) Modify ELF-parsing code in loader and kernel to check signatures and indicate whether a given file had good signatures for all of its loadable segments. 3) Have loader/kernel issue warnings or reject kernels/modules with incomplete/incorrect/no signatures 4) Decide how to go about building public key data into loader/kernel or how to register keys with the kernel (it is probably OK to implement a "bake it in" solution first, then figure out dynamic registration of keys as a follow-up; somebody out there is sure to want just the "bake it in" solution with no dynamic registration for security reasons, and we need it for loader anyway). 5) Submit a patch against GRUB to support the ELF metadata method in addition to their existing method. The most involved part of this is adding the public-key crypto code into loader and the kernel. My recommendation for this is to grab the RSA and ED25519 code from NaCL. It's compact, self-contained, written by crypto people with a good handle on the systems side of things (DJB's group), and licensed under a BSD-compatible license. Also, the loader/kernel side code only needs signature-checking, not full public-key functionality. =3D=3D Rationale =3D=3D The ELF metadata approach eliminates all of the disadvantages of the GRUB external signatures method, while maintaining compatibility with existing systems. Older systems will simply ignore the .signature metadata section and function normally and from a sysadmin standpoint, signed executables/libraries are just slightly larger versions of the unsigned variants. Moreover, ELF metadata that isn't part of the executable sections can be freely modified, and signed ELF files can be re-signed. Having a separate signature for each segment in the program header table is slightly more complicated than the simplest solution of having one signature for all program header sections. However, this approach provides more flexibility going forward. It also accounts for the fact that we might not want to sign all portions of the file. Finally, as designed, it allows the file to be modified freely as long as the runtime behavior isn't affected. There is a rather simple design possibility if anyone wanted to go the signed executable/library route: have an mmap variant with an additional parameter pointing to the signature would lead to a very simple modification of the userland dlopen functionality. Normal mmap would just become a wrapper around the secure variant, which passes in NULL for the signature (alternatively, you could pass in a default key built into the local libc, or something similar). =3D=3D Conclusion =3D=3D This seems like a good point in the design space: it doesn't break anything, it doesn't require massive changes or rearchitecting of anything, it provides everything I want to provide now, and it leaves the door open to things people might want to do in the future. Please provide feedback, comments, and suggestions. [0]: There actually is at least one example of something like this of which I'm aware. The Intel C Compiler (icc, "proton" by Intel internal naming) has an interprocedural optimization mode which produces .o files containing the compiler's intermediate representation in a special section as well as object code in the usual sections (incidentally, in the distant past, icc would actually produce separate .o and .il files; this was later changed to the ELF metadata solution, for the very reason that it complicated build scripts quite a bit). This allows "normal" compilers and compilation modes to use the object code, while icc uses the intermediate representation. --VfKDQGqN42otawkWgJ1TC8hPFp8JNnhaw-- --5tJFchSClLXPlLXBTeF3xliHxegxS2CGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljZUeQACgkQ1w0wQIFc o2cyhxAA2HlLeBeH5yEwzJyAq0oAkL0YVkFmrFUQpWh/jUWPvpWPmiWP/5m/lKnW ET1wttA2/2rIKa1N/G/Srm2NOSt38YHb4rTAs3fvcUi62mg4t7Lq1HDD1S9vLBtD EUe1agw9tHtGREmwVmkUaAKuprgNyDAhm0mbgjJpIk1KQpNHUojREIO8fzZUVzow KVtdRfmVJZOKFjk9Nl3Z7dDQoyWtQxnbP1Yss3jKXpgHwOfqgmFyqqGf0FtJ9G+Y IW7rb8wfMC8vTkblYFjR10jzpgd7wQNGa+bHb0qWQU5pdJA8mlLKnGVfUDxM2W8K 4eTNpKLHAi1avTz9oZ3tzigSgBBcf6s9kkfu50+lKpf8Cke/mH24sCGpLfCqb1Tu spcg0FbouvUhVMXT2zkZ9YgfTRyFcTcw+OIjCeWLr4vexIyMkdVwAPsZ7BK6E/bi odg9Pmm4Hy3SilSw8CIHGyUfx5UVZjUM4Ep6Y3jRoQ7CKiHC/lZK918R01qmJ5sR oDTyQnWo09Pf+w9/i6PP6Qo4313MJc/fk6QkWccbeWgaug9zVMw52nIS1d7i/lCw rS6Shq7pywEreAcc2FnMHXgafYJFVp+gPsNSTFXLCUjJS1ZbZUYGYA4XVkfnfBFf 5bCjT8R4amdp/OU5cOEEiMjGXqDnVjTX4XudFMEuHgZlC2CjBkU= =y53H -----END PGP SIGNATURE----- --5tJFchSClLXPlLXBTeF3xliHxegxS2CGS-- From owner-freebsd-security@freebsd.org Mon Mar 27 18:37:38 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 646BAD20730 for ; Mon, 27 Mar 2017 18:37:38 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 19797948 for ; Mon, 27 Mar 2017 18:37:38 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22e.google.com with SMTP id f11so46590657qkb.0 for ; Mon, 27 Mar 2017 11:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RbKMRDO2TFZMhcGD7fNKwTsEG+dL/ZG80nITzzt9IH8=; b=HnmSZAA9WKbl7NfLByBOF5o30xVxW+W0m+VaKM76TNmfI2rFlvsKU8DWcnyeiX4GOL TY2MIoDJhfvJ8sD99yLSZoOHAX+kQn3tURSZlaxoVAcLtRIP74aeT+JhbvyQtAPEcctn WI/nZn5lMXWBciaqaOINq5v/J9gjMtMSsC9xXGZd9tN2zOVc22SEQ8uRo3ze4f7aPBuN ZOzMG+b7dZvFR52VeSanOragLS6ml3QmvUHt+Aofplp8t+6ixjxCRgduMWhUWxq0eA4O n5FkmOu3Muq3e6HJO2L0M1NzXo28+NSXQTrMtJxqLiRPks0NCkHhzsZ60aHR+jZEdiA6 cazQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RbKMRDO2TFZMhcGD7fNKwTsEG+dL/ZG80nITzzt9IH8=; b=lw5P1V0g7wJdN1dYY5BFbL/eI+Dj3cGbpJt7gOkYJiU+9nkqyQXGvmwqnDUJRj4iWG mOWxjwhynDpPRLZzDiRfzM62c0KdypNebQxYcw+DjuH0ak6oQPO7bm7tQtGxXLSiq703 +XUqqr6pC379V3gYe5vLwG7nzNttrMmkLLz8SHi3lz9XQ2wqdvFsbzrrkQmXlScPHZJ3 kb1HmeWjj7GXpv0yB3KTpEwlg279OsTz+YlNfg35NiXzcwnyi5+X/u/09gl3qCBMWxMw U2huA2zIpfmKHloEKQ1UEGGZzGi5gr7kc6/n/bUvL51zQFx7o4IudByq5uEIEyOGX+bs B9uA== X-Gm-Message-State: AFeK/H3hU/uF/eCmtkcnWx62ttDQp8T/lIEzkCRNPwyIvokTDf51Nm3/t+6B9He9Wi+xGK6H X-Received: by 10.55.134.5 with SMTP id i5mr19528502qkd.29.1490639856888; Mon, 27 Mar 2017 11:37:36 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id d4sm920000qkf.30.2017.03.27.11.37.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Mar 2017 11:37:36 -0700 (PDT) Date: Mon, 27 Mar 2017 14:37:35 -0400 From: Shawn Webb 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: <20170327183735.uokjhjaafkawc2id@mutt-hbsd> References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2iuyerr5quyn3eol" Content-Disposition: inline In-Reply-To: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170206 (1.7.2) 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: Mon, 27 Mar 2017 18:37:38 -0000 --2iuyerr5quyn3eol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Eric, Thank you for writing this! ELF binary signing has been on my ever-growing list of things to research and develop. If you'd like help, please let me know. I have a few comments, which I've made inline. On Mon, Mar 27, 2017 at 01:54:44PM -0400, Eric McCorkle wrote: > Hello everyone, >=20 > 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. >=20 > =3D=3D Goals =3D=3D >=20 > 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). >=20 > 2) Be able to check for a correct cryptographic signature for any kernel > module loaded during normal operations (whether or not to do this could > be controlled by a sysctl, securelevel, or some similar mechanism) >=20 > 3) Work with what's in base already and minimize new additions (ideally, > just a small utility to sign executables) >=20 > 4) Minimize administrative overhead and ideally, require no changes at > all to maintain signed kernel/modules >=20 > 5) Have a clear path for supporting signed executables/libraries (I'm > not planning on pursuing this, but it's worth considering that someone > might want to) >=20 > 6) The design *MUST* support the case where a system builds locally and > uses its own key(s) for signing kernels and modules (and anything else) > and *MUST* allow the administrator complete control over which key(s) > are valid for a given system (ie. no "master keys" controlled by central > organizations) >=20 > 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) As git has shown, having a modular/configurable crypto interface is the best route. Right now, git is stuck using SHA1 because they didn't support users being able to choose which hashing algorithm to use. >=20 > =3D=3D Non-Goals =3D=3D >=20 > * Hardware/firmware-based attacks are considered out-of-scope (there is > no viable method for defending against them at the OS level) >=20 > * Boot platforms that don't provide their own signature-checking > framework up to loader/kernel can't be properly secured, and are > considered out-of-scope >=20 > * Boot platforms that impose size restrictions prohibiting incorporation > of RSA and ED25519 crypto code (ex. i386 BIOS) are considered out-of-scope >=20 > * GRUB support is desirable, however it is not necessary to support GRUB > out-of-the-box (meaning a design requiring reasonable modifications to > GRUB is acceptable). >=20 > * I am not aiming to support signed executables/libraries now, only to > avoid shutting the door on them. Since FreeBSD uses ELF for the kernel and its modules, it should be rather straightforward to apply the same work towards userland binaries and shared libraries. >=20 > =3D=3D Existing Solution(s) =3D=3D >=20 > EFI has a decent design with regard to key management (platform key, > which signs system keys, which sign the actual loader); however, its > cipher suite is sorely lacking (many broken hashes and weak ciphers, RSA > 2048 being the "strongest", no ECC). It also only works with the COFF > format, and is only available at boot time. However, it does provide a > chain of custody up to loader (to the extent that anyone trusts > closed-source firmware blobs, SHA1, and 512-2048 bit RSA keys...) Many > implementations also have master keys "baked in" that would allow > anything signed by random third parties (Microsoft) to boot regardless > of local configurations, or they don't provide any sort of control over > (or even access to) the keys at all. >=20 > EFI obviously isn't viable beyond boot time, and misses most of the > goals even there. Its key management hierarchy is an overall good > design, however. >=20 > GRUB currently supports signature checking. It can be configured to > require signatures for any of its own modules as well as any kernel or > modules that it loads. These signatures are stored *outside* the > executable/library, in a file with an added .sig extension. The format > is that of an external signature for the entire ELF file as produced by > the gnupg program. >=20 > Linux (I believe) also supports signature checking for modules using the > same convention. >=20 > While functional, this design doesn't meet the goals I outlined: >=20 > * It relies on the gnupg framework, which is not part of FreeBSD base, > and adding it would be a chore (and would end up duplicating a lot of > functionality provided by OpenSSL) >=20 > * It stores the signature separate from the file, which leads to x2 the > number of files, would require modifying existing scripts, and > complicates administrative tasks. It also leads to failure modes like > stale signatures. >=20 > * There are potential legitimate modifications to non-code parts of an > ELF file (such as the .comment section or other similar sections) that > would require re-signing the entire file. >=20 > * The previous two problems really start to look bad when you consider > signed executables and libraries, possibly with third-party > build/install scripts... >=20 > * Finally, the gnupg signature format doesn't actually seem to be > documented anywhere, or at least not anywhere that doesn't require a lot > of digging... >=20 >=20 > An alternate solution, which I believe is used in some places is to wrap > the entire executable in a PGP envelope-like format. This solves the > issue of an external signature file, but would require extensive > modification to the ELF parsing code, let alone the binutils programs > that read/modify ELF files. This solution also isn't > backwards-compatible at all. Old loaders/kernels will choke on the > signed libraries. Whatever is chosen, it should be fully-functional with only the utilities base provides. >=20 > =3D=3D Proposal=3D=3D >=20 > My proposal is to store cryptographic signatures within the ELF files > themselves in a non-loadable section (similar to the .comment section). >=20 > As background, the ELF file format has a number of different section > types, only some of which comprise the program/library/module's runtime > state. The ELF specification and tools provide some "standard" sections > with defined meanings, but nothing stops anyone from adding their own > sections. The ELF file format is quite flexible, and it is not > difficult to add custom metadata to an ELF file. [0] >=20 > 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. You might want to take a look at Microsoft's Authenticode. Microsoft made some mistakes early on that allowed attackers to easily trojan signed binaries. Your proposal up to this point makes those same mistakes. It's been a few years since I researched Authenticode, so I don't have any links or documentation handy. The conclusion Microsoft came to is that the file as a whole must be signed, including offset metadata. Essentially, you'd determine how large the .sig section needs to be ahead of time, create it and fill it with zeros, then sign the whole file, stuffing the signature in the zeroed .sig section. Same concept as calculating checksums of ICMP packets. This prevents attackers from modifying critical pieces of metadata, pointing them to maliciuos payloads. It also prevents attackers from appending malicious data to the end of a loadable segment (something Authenticode suffered from early on). >=20 > The exact format of this data can be discussed, but a design where the > signature array corresponds to the program header array seems quite > reasonable. The format of the signatures themselves should be something > from a well-defined standard, reasonably extensible, and supported by > tools in base. >=20 > =3D=3D Summary of Changes =3D=3D >=20 > The following changes would be required: >=20 > 1) Add a userland utility for signing ELF files (call it "signelf"). > This would be a pretty straightforward application of OpenSSL and libelf. >=20 > 2) Modify ELF-parsing code in loader and kernel to check signatures and > indicate whether a given file had good signatures for all of its > loadable segments. >=20 > 3) Have loader/kernel issue warnings or reject kernels/modules with > incomplete/incorrect/no signatures >=20 > 4) Decide how to go about building public key data into loader/kernel or > how to register keys with the kernel (it is probably OK to implement a > "bake it in" solution first, then figure out dynamic registration of > keys as a follow-up; somebody out there is sure to want just the "bake > it in" solution with no dynamic registration for security reasons, and > we need it for loader anyway). >=20 > 5) Submit a patch against GRUB to support the ELF metadata method in > addition to their existing method. >=20 > The most involved part of this is adding the public-key crypto code into > loader and the kernel. My recommendation for this is to grab the RSA > and ED25519 code from NaCL. It's compact, self-contained, written by > crypto people with a good handle on the systems side of things (DJB's > group), and licensed under a BSD-compatible license. Also, the > loader/kernel side code only needs signature-checking, not full > public-key functionality. >=20 > =3D=3D Rationale =3D=3D >=20 > The ELF metadata approach eliminates all of the disadvantages of the > GRUB external signatures method, while maintaining compatibility with > existing systems. Older systems will simply ignore the .signature > metadata section and function normally and from a sysadmin standpoint, > signed executables/libraries are just slightly larger versions of the > unsigned variants. Moreover, ELF metadata that isn't part of the > executable sections can be freely modified, and signed ELF files can be > re-signed. >=20 > Having a separate signature for each segment in the program header table > is slightly more complicated than the simplest solution of having one > signature for all program header sections. However, this approach > provides more flexibility going forward. It also accounts for the fact > that we might not want to sign all portions of the file. Finally, as > designed, it allows the file to be modified freely as long as the > runtime behavior isn't affected. >=20 > There is a rather simple design possibility if anyone wanted to go the > signed executable/library route: have an mmap variant with an additional > parameter pointing to the signature would lead to a very simple > modification of the userland dlopen functionality. Normal mmap would > just become a wrapper around the secure variant, which passes in NULL > for the signature (alternatively, you could pass in a default key built > into the local libc, or something similar). Userland shouldn't be trusted to enforce digital signatures. What if someone at link time specifies a non-default RTLD? To enforce digital signatures of userland binaries/libraries, the ELF image activator should be modified to verify the DT_NEEDED entries. >=20 > =3D=3D Conclusion =3D=3D >=20 > This seems like a good point in the design space: it doesn't break > anything, it doesn't require massive changes or rearchitecting of > anything, it provides everything I want to provide now, and it leaves > the door open to things people might want to do in the future. >=20 > Please provide feedback, comments, and suggestions. >=20 >=20 > [0]: There actually is at least one example of something like this of > which I'm aware. The Intel C Compiler (icc, "proton" by Intel internal > naming) has an interprocedural optimization mode which produces .o files > containing the compiler's intermediate representation in a special > section as well as object code in the usual sections (incidentally, in > the distant past, icc would actually produce separate .o and .il files; > this was later changed to the ELF metadata solution, for the very reason > that it complicated build scripts quite a bit). This allows "normal" > compilers and compilation modes to use the object code, while icc uses > the intermediate representation. >=20 The only other major thing to discuss is supporting public key chaining. Ideally, digital signature support should also support chaining multiple keys (similar to X.509 PKI). If the accepted solution supported cert chaining, then the solution would be more modular. I don't want to go down the route of the SSL/TLS PKI mess, but supporting chaining is a must in some enterprise environments. If we were to support chaining, we could even stuff the pubkey half of the key material into another ELF section, so that if a key becomes compromised, the old pubkey can be revoked from the trust store and a new binary can be generated with new key material. The trusted root doesn't need to be cycled as often. HardenedBSD, for example, distributes the pubkey that corresponds to the signing privkey inside the update tarball for binary updates[1]. This allows us to change key material often if desired without the user even noticing. [1]: https://hardenedbsd.org/article/shawn-webb/2015-12-31/introducing-hard= enedbsds-new-binary-updater Caveat with the above-linked article: hbsd-update has undergone additional changes not reflected in the original article. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --2iuyerr5quyn3eol Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAljZW+0ACgkQaoRlj1JF bu4IhxAAlmF0xnGQFGomaYjB2BKc0+oqgawlJ6Xeib0UVSVAl8U3DhnyOlTduTvC 7Olhu3XUqiVd2ggJwihlQJSZ0oO0HTqMx1bMm9uBFDpOQEzLA460ZITOIRiUprzl bEgiOTY4yGWtM9MkQSqhCZFomXqhVNOY4OxLNXp0eXmysug/gaNu9JQD6N2t14Hx e2dCBVAgitK9D/qbYYrxBo53wFQYCTqlQuzEBNG+V8rACrV4mIYFl9T07et02T9/ fMGyZCT/nnsBwyKawKK/M+y7PPnDNm8X5PeWhOgwRm9yfzg3qWRmTMak3NLP5C1+ hqvobjTZcFA2wdRy6Ur8kHcEtSPR7fwgljFzNsK1usLCMBfKZkM19/iTHgdno70l S6gvd4ZKlQb9MgBx2ykBIbC18JfT7mubxQTav09nPB/tk1t+L2HF5MjE8Wx0+eeK YqJSxD3SyH3Q3zixFti5rePQKxlwhHOOZzQR443e7TuPC9iWtIn5rz1ON5xPsHZS jY78nmU1w0DvZoKc/WaMOQWhLaR9P7Oh3T7Urwsa+W0RDmYoZIHvqf3lOb+Kq+Wv SHSNe8EwQvUzIm/aF47G+cNiwHhocxWVWTqpFemWMzyiAxBV0YGFELzvMiYiL1YP logTqsSKQeXYhdL30J7I5Rf2eMXjCNmaFhh9Z6/3qDq9yPu1XLg= =C5y9 -----END PGP SIGNATURE----- --2iuyerr5quyn3eol-- From owner-freebsd-security@freebsd.org Mon Mar 27 19:53:37 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 03569D20C09; Mon, 27 Mar 2017 19:53:37 +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 CBB88EF1; Mon, 27 Mar 2017 19:53:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (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 435EA16E9; Mon, 27 Mar 2017 19:53:30 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: Shawn Webb References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org From: Eric McCorkle Message-ID: <0943546b-2dcd-597b-e000-38926e55bc1d@metricspace.net> Date: Mon, 27 Mar 2017 15:53:26 -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: <20170327183735.uokjhjaafkawc2id@mutt-hbsd> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="os7uND0ljmwv50huqBfTW7U8F7ROtLvM1" 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: Mon, 27 Mar 2017 19:53:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --os7uND0ljmwv50huqBfTW7U8F7ROtLvM1 Content-Type: multipart/mixed; boundary="dVQm9PL85J3IvOTUk061HHwJiacf7UQHs"; protected-headers="v1" From: Eric McCorkle To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <0943546b-2dcd-597b-e000-38926e55bc1d@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> In-Reply-To: <20170327183735.uokjhjaafkawc2id@mutt-hbsd> --dVQm9PL85J3IvOTUk061HHwJiacf7UQHs Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/27/2017 14:37, Shawn Webb wrote: > Hey Eric, >=20 > Thank you for writing this! ELF binary signing has been on my > ever-growing list of things to research and develop. If you'd like help= , > please let me know. I'll probably spin up a branch on my github in the near future. > As git has shown, having a modular/configurable crypto interface is the= > best route. Right now, git is stuck using SHA1 because they didn't > support users being able to choose which hashing algorithm to use. Oh yes! And all current pubkey crypto has an expiration date probably between a decade and a century from now. > You might want to take a look at Microsoft's Authenticode. Microsoft > made some mistakes early on that allowed attackers to easily trojan > signed binaries. Your proposal up to this point makes those same > mistakes. It's been a few years since I researched Authenticode, so I > don't have any links or documentation handy. >=20 > The conclusion Microsoft came to is that the file as a whole must be > signed, including offset metadata. Essentially, you'd determine how > large the .sig section needs to be ahead of time, create it and fill it= > with zeros, then sign the whole file, stuffing the signature in the > zeroed .sig section. Same concept as calculating checksums of ICMP > packets. >=20 > This prevents attackers from modifying critical pieces of metadata, > pointing them to maliciuos payloads. It also prevents attackers from > appending malicious data to the end of a loadable segment (something > Authenticode suffered from early on). Yeah, now that I think about it, there's various forms of evil you could pull off. I don't doubt that someone *could* design a scheme that would defeat all these attacks, but... is it worth it? Probably not. Better to just sign the whole file and seal off all the attack vectors, on second thought. > Userland shouldn't be trusted to enforce digital signatures. What if > someone at link time specifies a non-default RTLD? To enforce digital > signatures of userland binaries/libraries, the ELF image activator > should be modified to verify the DT_NEEDED entries. True, I was assuming dlopen just mmaps everything... (I was getting hungry by that point). As with the whole-file sigs, it would probably be better just to have a single syscall that securely loads dynamic libraries (but that's out-of-scope for now). >=20 > The only other major thing to discuss is supporting public key chaining= =2E > Ideally, digital signature support should also support chaining multipl= e > keys (similar to X.509 PKI). If the accepted solution supported cert > chaining, then the solution would be more modular. I don't want to go > down the route of the SSL/TLS PKI mess, but supporting chaining is a > must in some enterprise environments. >=20 > If we were to support chaining, we could even stuff the pubkey half of > the key material into another ELF section, so that if a key becomes > compromised, the old pubkey can be revoked from the trust store and a > new binary can be generated with new key material. The trusted root > doesn't need to be cycled as often. HardenedBSD, for example, > distributes the pubkey that corresponds to the signing privkey inside > the update tarball for binary updates[1]. This allows us to change key > material often if desired without the user even noticing. I can see a two-tiered scheme where you have a "vendor key", which is used to sign various "application keys", which are used to sign the kernel and modules. The signed executables can then supply their application keys (signed by the vendor key) to the loader/kernel, which first checks the signature on the key, then on the file. This way, you could generate and use a different key for each build, and sign it with the same vendor key. There's at least three use cases in play here: 1) FreeBSD would want to publish ready-made installations, probably signed by a key they control. This ensures that someone who just wants to install binary packages and go doesn't load any kernel/modules other than the ones coming from FreeBSD. 2) I run an enterprise network, and I want to build everything internally on some build-box, and make sure I only run things that got built there, or that came from FreeBSD. 3) I have a highly secure network that is set up like in (2), except I only allow things I build internally to run. 3) I have my laptop, and I want to build everything on the laptop and make sure I don't boot anything I didn't build. For all of these, I'd want to bake in at least the vendor key(s). I could do this pretty easily by converting the key(s) to a header, then using it in buildworld/kerrnel. For (1), FreeBSD would have a vendor key, which it uses to sign the kernel/modules it publishes, and that would be baked in to those applications. For (2), I'd have my own vendor key for my organization, and I'd use that in addition to FreeBSD's key. This would allow anything signed by either of the two organizations. For (3), I'd only use my own vendor key, and not FreeBSD's, so that only things I build internally can boot. For (4), I theoretically only need one level of key. I'd presumably generate a key pair every buildworld/kernel, then throw away the private key when I finished. OTOH, I'd need to remember to reinstall loader (or GRUB/coreboot, and I might not want to go around flashing my BIOS every time I upgrade) every time, so there's a case for a two-level scheme at which point it's a microcosm of (4). --dVQm9PL85J3IvOTUk061HHwJiacf7UQHs-- --os7uND0ljmwv50huqBfTW7U8F7ROtLvM1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljZbbYACgkQ1w0wQIFc o2eVyhAAihBjJebgTcoQQO/d9eTgC1QhQzw98Kd5PqDqskVKjBh49GARLZXG0mvg 3ayZE6tmL5qJjJkJirqr9IDn3bfCIbBhv4Mz8fA5dj9uiu+H/ph0FZBlmntejzMe yFDLc+vEKcCB2OJQyf7X9XiEOPWoZDmZKx1Wb2T6OQNZ7n+Ud9Rnbw/wDjgzCgbI zeN21MLI1+94RrAyGlf83uQAd6TDIkI8BV99+mA/6sZKEHL4AdsOfmzwt/XxMYxW oXqednrF+fi6fy8j6t0INERXRkS9lg1i7xUdEOs6Sr30nimPaNyDicgm/W2YpJOa /wWtRBh3Dt0A/GRfa+hODPy5dPmB7OMF0OIqfH0VsmwhdQf0C/fMvsuqs5yIcjvX a8dlBVqDCyCfGI17w6UhXyviGNlcW/vQXc9XiibHFBwHd+uWMBF32W0HB4ecEvJA bALiuSGthBFUKL/7vT3a07eAWlAdEOtETANrionXY/AIw1tpbaJypjuKL4r092qB PKoBbnCSwtl3SPPIxAbzKzX4CgFaBafTMruM0R8QNPolTZ70de/hMEcWxTt0kiP8 iQtGNdlire+KRe2+3dQ3LUh5gIAne1wIBCNtuTyiHEiv0340JX9KGJUgBgGQobkO GSIN4mkUQFbI7926jYcFM62Qk61+2eFv68j1PXIacwXBlEd/bkw= =NkKn -----END PGP SIGNATURE----- --os7uND0ljmwv50huqBfTW7U8F7ROtLvM1-- From owner-freebsd-security@freebsd.org Wed Mar 29 05:16:13 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 E3886D238E7; Wed, 29 Mar 2017 05:16:13 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) (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 6F5E465082; Wed, 29 Mar 2017 05:16:13 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wm0-f47.google.com with SMTP id o81so13467654wmb.1; Tue, 28 Mar 2017 22:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=cfaL7d0AYAdRMg9CVapyydtP2Zwlp2vaWMhd8ZJys94=; b=buLBmgJoeAkuGlAqx9pjeb6snCsZbgoxn/+bSJjciZSnDmD/xmSf9yDxAuetAtDbYa m0kOnM5txbQnysMYIhr9bUtsDTRnWxngH1CCIguyfStioZQBJMbvxnGpc5HMBRL0OMMk UTSHlJw8XyZ3czZGdRzErac210kw5HtN9HAbflOSCtYU8G+IeiJu6lUUznS4TcF6lPyx 8Hd9z12Kkf2WH2GA3ZFflco7u4SswOCves4cURVvgXNXX+j6x8RFVuooKzGhbJ15Wtf9 0kHW4/9YOhq1zv8fRKUSOAYSPSAgYA3U6B1b/9b9hI+sOyOm9lopHRwe7ru4IZzLhHcU /Y/g== X-Gm-Message-State: AFeK/H1YKNS49wxINlofs3NxADXnRss6ASrEyxLIADGjsQFidC8vNf2oN299L3l3bq7Abg== X-Received: by 10.28.15.12 with SMTP id 12mr17290810wmp.22.1490764565575; Tue, 28 Mar 2017 22:16:05 -0700 (PDT) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com. [74.125.82.45]) by smtp.gmail.com with ESMTPSA id h3sm7469138wrb.6.2017.03.28.22.16.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 22:16:05 -0700 (PDT) Received: by mail-wm0-f45.google.com with SMTP id u132so54631190wmg.0; Tue, 28 Mar 2017 22:16:04 -0700 (PDT) X-Received: by 10.28.232.21 with SMTP id f21mr12158120wmh.0.1490764564852; Tue, 28 Mar 2017 22:16:04 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Tue, 28 Mar 2017 22:16:04 -0700 (PDT) In-Reply-To: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> From: Conrad Meyer Date: Tue, 28 Mar 2017 22:16:04 -0700 X-Gmail-Original-Message-ID: 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-Mailman-Approved-At: Wed, 29 Mar 2017 11:50:10 +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: Wed, 29 Mar 2017 05:16:14 -0000 Hi Eric, Your proposal seems reasonable to me. Others =E2=80=94 if you don't have time to read the full email, start readi= ng at "=3D=3D Proposal=3D=3D" for a summary of what is actually proposed. You can go back and read the earlier part of the email for some discussion of requirements and other options/context. Thanks, Conrad From owner-freebsd-security@freebsd.org Wed Mar 29 12:16:18 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 0835AD23100 for ; Wed, 29 Mar 2017 12:16:18 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) (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 A90B669272 for ; Wed, 29 Mar 2017 12:16:17 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from office.storpool.com (unknown [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id 5E8B724E for ; Wed, 29 Mar 2017 15:10:53 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 25403fc by office.storpool.com (DragonFly Mail Agent v0.11); Wed, 29 Mar 2017 15:10:52 +0300 Date: Wed, 29 Mar 2017 15:10:52 +0300 From: Peter Pentchev 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: <20170329121052.l6e7ajvvq6yfltpt@office.storpool.com> 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2y6ant3anwcqndju" Content-Disposition: inline In-Reply-To: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> User-Agent: NeoMutt/20170113 (1.7.2) 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 12:16:18 -0000 --2y6ant3anwcqndju Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2017 at 01:54:44PM -0400, Eric McCorkle wrote: > Hello everyone, >=20 > 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. >=20 > =3D=3D Goals =3D=3D >=20 [snip] >=20 > =3D=3D Non-Goals =3D=3D >=20 [snip] >=20 > =3D=3D Existing Solution(s) =3D=3D >=20 [snip] > While functional, this design doesn't meet the goals I outlined: >=20 [snip] > * Finally, the gnupg signature format doesn't actually seem to be > documented anywhere, or at least not anywhere that doesn't require a lot > of digging... Erm, actually, the so-called "gnupg signature format", better known as "the OpenPGP signature format", is pretty well documented in RFC 4880. Note that this remark has no bearing on any of your other arguments, or on your work as a whole; I just wanted to clarify this particular point :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --2y6ant3anwcqndju Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAljbpEwACgkQZR7vsCUn 3xOT7w/+Ico4GO6e9BFic2UJs4n3cgyo/tzEwbV+JZ75w5uhPHeBmxsQo6q49Bbu JaCas1w7mPpDIiKK5oBLUTDVSEsHyDfBfBQn6yY7qax/pehi8EAAmxy6cLBj5LNL 4BJUrUbGlJVWe4Y/kxFiCxUhkDYTHzJTv7G2BsQeH/xGDhAnXtcNs7TSpxuTrUK8 jimOKLWNmxUPLuxTPIDuVmzV6nXFc7wrrdiqWOyaxOG7t16auuaou0OHIs0PBxND ZIXh5OBXQWhIW1DhQBTx5Anmi6oihOzeQSw1Ppt7OMoIbpZVwX+y8VYW6NFDCa9H 1xuLdqsxnMGuUsZw0QAgEfnEU7oFXnmhjcGLFL0AOabk2vP820bLhWNYefBDXlFw WYW677hrpCnNMT8SphUE4uHURJ93RnSudwRQVpkb6pdRAUr2iIOx3R6gsqJhs7gU HiUzoiiMhcizKyXRjrYLDL131HD1fCXwk967I7ggcDccfJ3v0FWblacMYsfRy8mT yS6234vL10tRkFMifQ65s5EVzsfiTUxYJubJhnGBqDWhiWrpytqQogRtgYqBbp3t zimxG8/jZ/h6eM+BeQuEdz9qqCwCa+Y+fUhV3SA7UEhpJKW3fXkKB6sFTagVjTyD 1pfQ7iUySFdnDDmMvOd/SJFU5jYfWRPUMy38iXD90T4jUSYtd54= =aH/a -----END PGP SIGNATURE----- --2y6ant3anwcqndju-- 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 From owner-freebsd-security@freebsd.org Wed Mar 29 14:02:05 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 E16D7D23BAE; Wed, 29 Mar 2017 14:02:05 +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 B78523D35; Wed, 29 Mar 2017 14:02:05 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (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 1AE4116AF; Wed, 29 Mar 2017 14:02:05 +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> <20170329121052.l6e7ajvvq6yfltpt@office.storpool.com> From: Eric McCorkle Message-ID: <5f2e1bf1-947d-3e2d-b7e4-034f8f1af3e9@metricspace.net> Date: Wed, 29 Mar 2017 10:02:02 -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: <20170329121052.l6e7ajvvq6yfltpt@office.storpool.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g9p1eA8eXHkgsXgRu9Obp2UkogJhfcsTg" 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 14:02:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g9p1eA8eXHkgsXgRu9Obp2UkogJhfcsTg Content-Type: multipart/mixed; boundary="SOUBPUWIbUil86cK1NdLg2cFwNoTC56vo"; protected-headers="v1" From: Eric McCorkle To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <5f2e1bf1-947d-3e2d-b7e4-034f8f1af3e9@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170329121052.l6e7ajvvq6yfltpt@office.storpool.com> In-Reply-To: <20170329121052.l6e7ajvvq6yfltpt@office.storpool.com> --SOUBPUWIbUil86cK1NdLg2cFwNoTC56vo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/29/2017 08:10, Peter Pentchev wrote: >=20 > Erm, actually, the so-called "gnupg signature format", better known as > "the OpenPGP signature format", is pretty well documented in RFC 4880. > Note that this remark has no bearing on any of your other arguments, or= > on your work as a whole; I just wanted to clarify this particular point= :) Noted, though I think I'd prefer a format that's directly supported by OpenSSL. > G'luck, > Peter >=20 --SOUBPUWIbUil86cK1NdLg2cFwNoTC56vo-- --g9p1eA8eXHkgsXgRu9Obp2UkogJhfcsTg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljbvloACgkQ1w0wQIFc o2e1jw//Vo9ldXF8hVgQKTxCcHneVlCwsgqh0CacUs2GRj4aufoSSlqj9cQgVoEv gyTFd4sgx5MZ/7l1XRN1lBFsT0ulTb+ey+43JLFdRMfPaMZeID4+m7R2sCmIDK3N 2mYsBC74tZ3OEc0cmHQNQkLgccG+0/XF7qtdafJVulM85+mH7jefvVyZx7mCUX2r W5L9CW4QL0+SusRfzLZ9TZ8VsD/Kiw0rWtiV77/7VxAVRaDLPTR8mSRwM81Du4gR SE6eLROJdLmxOWNbm7Q7/pFYlZ0OCLUGWTic+UsU3lSXlJBg2O26PA5FelZ9PaJh T2g3ADBGgSuvZGFlCAUj2MgP2IGaCJk+ZTCaHIsPiSjpD0T35G126nMPTkzFyFlz DOB13wDwcjbW7w9adGSxf3qkQ46xf2vD4PtrCDf0VhkxtaqjbdXRkk8BXxD/YRgH oSCkHl39Z2l4s4CdMt43xnwaJuflGc8vuDEkcpbSdpwHir1h61sqmRn3F/XOzBDC Mu4oUhjpgviUnUSwDI9FkE+/ba2OnZbDi0/V2ktUzOm2ObyuZ6IJFXrdntrr+/J8 aCfEHt+gH/xca3z/Nf/rmx+3ewTLpFpfKq1T5lrhX5w8YZOyUyoudtjN31wLEP6M 2P9Pc0WKVtBmXz3nKj5Bhn3a4uqJJTHJfwVYqDrokiUfTWmOlR0= =pNNj -----END PGP SIGNATURE----- --g9p1eA8eXHkgsXgRu9Obp2UkogJhfcsTg-- From owner-freebsd-security@freebsd.org Wed Mar 29 14:27:51 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 4A98AD234E2 for ; Wed, 29 Mar 2017 14:27:51 +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 1941E67655 for ; Wed, 29 Mar 2017 14:27:51 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (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 9741416DC; Wed, 29 Mar 2017 14:27:50 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: Michael Richards , freebsd-security@freebsd.org References: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> From: Eric McCorkle Message-ID: <9a26934a-613e-a4fa-7f27-5e1c35f5bb8c@metricspace.net> Date: Wed, 29 Mar 2017 10:27:46 -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: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8" 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 14:27:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8 Content-Type: multipart/mixed; boundary="FU6BXL3r0HquNG4efSAVX0x94ksOFRulV"; protected-headers="v1" From: Eric McCorkle To: Michael Richards , freebsd-security@freebsd.org Message-ID: <9a26934a-613e-a4fa-7f27-5e1c35f5bb8c@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> In-Reply-To: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> --FU6BXL3r0HquNG4efSAVX0x94ksOFRulV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2017 09:54, Michael Richards wrote: >> 1) Be able to check for a correct cryptographic signature for any kern= el >> or modules loaded at boot time for some platforms (EFI at a minimum). >=20 > 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. There's a couple of use cases I envision: 1) EFI solution: Build a verification key (see my response to Shawn Webb for a discussion on vendor/application keys) into loader.efi, and set up EFI secure boot with boot1.efi and loader.efi. The EFI Secure Boot framework checks signatures on boot1.efi and loader.efi (since boot1.efi uses EFI API calls to load loader.efi). Then loader.efi does the signature check as I've proposed. 2) GRUB solution: GRUB would need to be patched to use the scheme I've proposed; however, the rest is all existing GRUB functionality: you can establish a trust key in the GRUB config file and configure GRUB to enforce signature checks. You could boot from EFI secure boot, or you could install GRUB as a coreboot payload (the coreboot payload is the solution I'm planning for myself). I suppose you could also engineer more exotic solutions like having keys on a separate USB dongle, but I'd want to aim for the basics at first. (Some of my other pending work might help with this, actually) >=20 >> 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) >=20 > 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. >=20 Do authenticode keys come in a standard format known by OpenSSL, or can they be converted to one? It seems like what you really want is to be able to use a key that some trust authority has signed; that should be achievable as long as you can convert to a format that tools in base can recognize. Depending on the key size and ciphers, though, it might be wise to have some kind of ALLOW_WEAK_CRYPTO option. Microsoft does has a history of using weak ciphers and short keys... >=20 > 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 schem= e > here is a bit complicated. Once an executable or library is produced an= d > 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. Note that I walked this back to just signing the whole executable after Shawn Webb's response. >=20 > As an extension to this idea, it would be interesting if a database of > exploitable system .exe and libraries were maintained. It would be hand= y > as an admin to have an immediate report that library XYZ on your system= > is exploitable and needs your attention. That sounds like portaudit more or less for binaries. It's an interesting idea, but I think it's a separate effort. --FU6BXL3r0HquNG4efSAVX0x94ksOFRulV-- --6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljbxGIACgkQ1w0wQIFc o2cc9hAAkd3ux5hQzGmx1rlTZs4n1rJXmuoLzE8ZExzNnV2qexI6HXOZqE7pUIvD xFuZPfFlVxKOOaWzt+XzEXe9wD3SrmfrmomMvUyN+L8ptUZekuEi6+5qe4gI59aE H4T/8N798qn47yxjFx27pRjnAyJxVyXONRglAbHXyP/nAdYE3DeaNuRz0FP87Hwr tu4sVKqH1F5m1YPpCThiIExhqPENSBjj92b41qEj3lOY57K2fH0FEz2jOZ2WD/QA wPWsVRDOeEZjEIrh0x32V35O22LPdoK/l+/XTCsSjyxn9yaqkMoExHoHUNDiiqMe 4vMR0J2pJERpvt8mLScTcVz+7tla7jJZl51nHFBAxhEP7CKMdWB3QGWzHK6Pv0I6 zPNCZcuRFH3XafgonDldZDer3W+1ejuJtpw9FlBKDYtpvDfC05XI9A2uDy9NZfcw K3YgUNsgXRqiTvRm+EykdEug6nL3V3KlexIGe8+md7bwRQK8bbQp/T8bvK44DvfB Xt702PJ3u2oRucuATIPydaw4Fz1kswYiMDtsP+bK53AdvVElMWBACHkXxDTrc9PF /bsLe2ysetTdXofzrIViRLW9y0pZgxfGWl0u06okTRDq3oY3TLmU55oKXRXJpDIP SCliYvqiDh0Az7wQKBfCBumATEOITuCM7JhlBonBU+liQlurcuQ= =vaCT -----END PGP SIGNATURE----- --6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8-- From owner-freebsd-security@freebsd.org Thu Mar 30 02:22: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 31E7BD25425; Thu, 30 Mar 2017 02:22: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 DF200BB8; Thu, 30 Mar 2017 02:22:45 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (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 F19FA18D6; Thu, 30 Mar 2017 02:22:44 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: Shawn Webb References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org From: Eric McCorkle Message-ID: Date: Wed, 29 Mar 2017 22:22:41 -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: <20170327183735.uokjhjaafkawc2id@mutt-hbsd> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o2TtOFM9E1kLqGqmdpTQ5s2xSHI3daBLW" 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: Thu, 30 Mar 2017 02:22:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o2TtOFM9E1kLqGqmdpTQ5s2xSHI3daBLW Content-Type: multipart/mixed; boundary="Di4UCV0TwwPjjxxo7nhqsEfixbrNrXmGj"; protected-headers="v1" From: Eric McCorkle To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> In-Reply-To: <20170327183735.uokjhjaafkawc2id@mutt-hbsd> --Di4UCV0TwwPjjxxo7nhqsEfixbrNrXmGj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/27/2017 14:37, Shawn Webb wrote: > The only other major thing to discuss is supporting public key chaining= =2E > Ideally, digital signature support should also support chaining multipl= e > keys (similar to X.509 PKI). If the accepted solution supported cert > chaining, then the solution would be more modular. I don't want to go > down the route of the SSL/TLS PKI mess, but supporting chaining is a > must in some enterprise environments. >=20 > If we were to support chaining, we could even stuff the pubkey half of > the key material into another ELF section, so that if a key becomes > compromised, the old pubkey can be revoked from the trust store and a > new binary can be generated with new key material. The trusted root > doesn't need to be cycled as often. HardenedBSD, for example, > distributes the pubkey that corresponds to the signing privkey inside > the update tarball for binary updates[1]. This allows us to change key > material often if desired without the user even noticing. I've done more research and design work in this area, to the point where I think I can talk about specific formats. I've also done some really preliminary work on the signelf utility (just sketching out the various use cases and marking the API calls I'll need, no real implementation yet). Here's what I've got: =3D=3D Use Cases =3D=3D The command-line utility ought to be able to verify signed ELF files too (so people can sanity check things). There's basically three cases that emerge for signing: 1) Vendor key + ephemeral key: I point you at the vendor key-pair (the public key for which is presumably compiled into the loader/kernel), you generate an ephemeral key-pair. You then sign the ELF with the ephemeral key-pair, sign the ephemeral public key with the vendor key-pair and include it in the ELF as well, then securely delete the ephemeral private key. 2) Direct signing with an application key: I point you at an application key-pair, which is signed by a vendor key somewhere (which is presumably compiled into loader/kernel). You sign the ELF with the application key-pair and include the signed application public key in the ELF as well. (Case (1) is basically the same as this one, except we generate and sign a one-time application key) 3) Direct signing without a vendor key: I point you at a key, which you use to sign the ELF; however, you don't include the public key in the ELF (it's presumably compiled into loader/kernel). On the verification side, you have two cases: A) ELF with signed application key: You have a set of vendor public keys. The ELF has a signed application public key and a file signature produced with said application public key. You check that the file signature is valid using the application public key, then check that the application key signature is valid using the vendor public keys. B) Direct-signed ELF: You have a set of vendor public keys. The ELF has a file signature produced by one of them (presumably). You check that the file signature is valid using the vendor public keys. Cases (1) and (A) should be the default behavior on both sides, and the signelf utility ought to be able to batch-sign a whole bunch of files with one ephemeral key. Case (2) is included in anticipation of a situation where it's not feasible to do all the signing in one fell swoop. Cases (3) and (B) are simplified behavior for when a vendor key isn't needed (ex. some kind of all-in-one embedded system image). =3D=3D Formats =3D=3D There are two formats (or rather, families thereof): * OpenSSL- formats based around ASN.1 DER and PEM, PKCS#8 format for private keys (which supports both encrypted and unencrypted storage), X509 for public keys, PKCS#7 or its successor, CMS for signatures. * OpenPGP (GnuPG) formats OpenSSL is directly supported by base, and is arguably more widely-used (it's the foundation for SSL/TLS). It also provides direct support for cert-chaining as I discussed in the use case analysis (in fact, it can go way beyond that). GRUB needs public keys to be in GnuPG format. On the other hand, the gnutls library handles X509 and PKCS#7. There's also some interesting possibilities with vendor keys and PGP's web-of-trust functionality. Fortunately, the monkeysphere project (port security/monkeysphere) comes with utilities for converting between OpenSSL certs/keys and GnuPG keyring databases. With this in play, it just makes sense to use the formats that are directly supported by base. =3D=3D Specifics =3D=3D So, here's what I'm proposing WRT the gritty format details: * The command-line tool will expect to see public keys in X509 format and private keys in PKCS#8 format, both with PEM encoding. * The vendor keys will be stored in a standard location (say, /etc/keys or something), and there would be a build utility that converts the public keys into a C file containing the data, so it can be baked directly into loader and kernel. * A signed ELF will definitely contain a .sign section containing a single detached signature in PKCS#7 format with DER encoding. * Signatures are computed by hashing the contents of the entire file minus the .sign and .cert sections. (Crypto hashes effectively consume a byte stream, so this is pretty straightforward to do) * A signed ELF may also contain a .cert section, which contains a single X509 certificate. In use case (1), this would contain the ephemeral public key. In use case (2), this would contain the application public key. In use case (3), this section would be omitted. You could presumably include an entire cert-chain here, but I think that's probably overkill. An alternative to the .cert section would be to have the ability to point kernel/loader at an X509 cert and pull the whole thing in as long as there's a root signature coming from a valid vendor key. I'm a bit split as to which one is better, though I seem to like the non-.cert solution the more I think about it... --Di4UCV0TwwPjjxxo7nhqsEfixbrNrXmGj-- --o2TtOFM9E1kLqGqmdpTQ5s2xSHI3daBLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljca/EACgkQ1w0wQIFc o2dBtw/+M8Z/03eZqrmkN0WElSirvQTLU/orKe4t/XPJ+Rv7kqI3KjRhQEb76+0T 1KNJJrnhmiRiu9CEy8kVbatUQ75Hz5VmB4fbl4CeW5GQERSgaUp2ErPXT6Y4dENN dBc+yT+Sf0i1csN2lsfIVxD15bC+VweSuBDdsWHeEk7IjMBBNKaJ3TNxsGLTDV9f zgyiXLmwqgUXiR8l8dM3WavbwCdy0O9u/aNTS7gz+cFaeIRyjZaO7+041DSFFdjv ObymfvWCVEXmkIfFmsmtXCKCQSjJhyMmiqFYSKL2etM+gE0tdl9xHhjkviTXT7ov GlZCzxocLG1vMhzEfj5zEWOqHrQuu1NKmtSXv9yyaLGIHiTPSlro9bgDAlTlaThC vte3SRYNcFgazGTez2F8oqW87MrzsHzBA+hoeAbSyYiOO79e2EvgfmHsDxn/SvYl XGUHPPD+5OFek1wC28e/ofO3d99AMICZZzd5xc5Zif+JdAmSX6JeKk5HtqsXhk1P cV4s2ZF07PX8gHfcQtJJGz7TqJKZGdiV3iXZOrMaKQ/hmJ1R602M5pyMKH27sP8p e78IhlWw1tREbP0Koqk5Lrws5yFWyxaOr8TZobfhPYW3ZgvCAEbVVsFykOp3VXyu SLXSHiMInY7v55ih0johhh5YpXvCPj6xcYK5sW9HK5WbRoLu1/o= =qvz6 -----END PGP SIGNATURE----- --o2TtOFM9E1kLqGqmdpTQ5s2xSHI3daBLW-- From owner-freebsd-security@freebsd.org Thu Mar 30 03:25:34 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 98986D17918; Thu, 30 Mar 2017 03:25:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 0ACF769C; Thu, 30 Mar 2017 03:25:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2U3PSAv094977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 06:25:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2U3PSAv094977 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2U3PSPq094976; Thu, 30 Mar 2017 06:25:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Mar 2017 06:25:28 +0300 From: Konstantin Belousov 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: <20170330032528.GT43712@kib.kiev.ua> 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-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: Thu, 30 Mar 2017 03:25:34 -0000 On Mon, Mar 27, 2017 at 01:54:44PM -0400, Eric McCorkle wrote: > As background, the ELF file format has a number of different section > types, only some of which comprise the program/library/module's runtime > state. The ELF specification and tools provide some "standard" sections > with defined meanings, but nothing stops anyone from adding their own > sections. The ELF file format is quite flexible, and it is not > difficult to add custom metadata to an ELF file. [0] > > 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. First, you mix or do not understand a difference between section and segment. Second, this scheme allows to add loadable segments after signing. Third, most important, it has zero chances of working for amd64 modules. From owner-freebsd-security@freebsd.org Thu Mar 30 03:28: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 3FBDBD17C11; Thu, 30 Mar 2017 03:28: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 15619A26; Thu, 30 Mar 2017 03:28:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (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 1BD361911; Thu, 30 Mar 2017 03:28:45 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: Konstantin Belousov References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170330032528.GT43712@kib.kiev.ua> Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org From: Eric McCorkle Message-ID: <164dec90-bfa3-4446-2ecb-49b257188d42@metricspace.net> Date: Wed, 29 Mar 2017 23:28:31 -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: <20170330032528.GT43712@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="02EUP2gS58WSV5tTurcbE566WE2PgVkSs" 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: Thu, 30 Mar 2017 03:28:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --02EUP2gS58WSV5tTurcbE566WE2PgVkSs Content-Type: multipart/mixed; boundary="R4DT45iS3jdpLXk254IxS0UoUD1adVm26"; protected-headers="v1" From: Eric McCorkle To: Konstantin Belousov Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <164dec90-bfa3-4446-2ecb-49b257188d42@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170330032528.GT43712@kib.kiev.ua> In-Reply-To: <20170330032528.GT43712@kib.kiev.ua> --R4DT45iS3jdpLXk254IxS0UoUD1adVm26 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/29/2017 23:25, Konstantin Belousov wrote: > First, you mix or do not understand a difference between section and se= gment. > Second, this scheme allows to add loadable segments after signing. > Third, most important, it has zero chances of working for amd64 modules= =2E That design has been abandoned in later discussions. --R4DT45iS3jdpLXk254IxS0UoUD1adVm26-- --02EUP2gS58WSV5tTurcbE566WE2PgVkSs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljce18ACgkQ1w0wQIFc o2f9kw/5AXtlmgobBmv1OUs4fhHn6i4+2PFV/nJey5twu3kyuJQZdUwl4TIudVy3 +ycN6lds4inoMfd+vx3sBCDW9rlN7L9/Ovuq6fYy3DBhX6k8GncCcgHyLpu9Wwxa U3IRW+mRUzo6feOnxl//0h6gqJzHWAIoxTlB49Lyh9gbwZWdVd+Mammj/i5FDgrp iaC57Zz1G/zlm0Ry4No7kloMUoJJXOPy1+ZBnM2VlGpA94hcJVCy5tnbQbMATQd9 6sJwGyW3ofOkr4b8/jzjK7N2wPHr/0JRZufMrxxarKqz8eRS6xtPf7ZNLV83oVxc rt/mPFiH+ZcWDtek1RlNNKUsvAmMzdy18G7QF0n8knI0YsW4Iv1dJts6TodRfhOm pDk0Iau+7bIe0LnALN82N2lMH9zwUE+iykYQC3SttooNRhYGs3lU4/MN7bt3Z3EB ErT5tadl6y8aRgMsO+1M1xAdF+AsrQ5WX31Op+2kCS3/PtDE3G2uP1xh2KJXYjPN s+WyU0n+THlqN2LIw4cESrnlEZUcVmqtjGcTjyQYbYNw8w6rZOSAECGZ9YOi+A78 FXJijg3HwcZ/Uv+KrnjpWTnnXYy8YPDcmq0zankjGwDEmUtfsalpqm2VpCTyjct9 ucgEPDX97GQTt0j3ZDRhSmPOzbYRmAAa0i9j+1BaNeRWbBH6SEk= =dYAg -----END PGP SIGNATURE----- --02EUP2gS58WSV5tTurcbE566WE2PgVkSs-- From owner-freebsd-security@freebsd.org Thu Mar 30 18:05:10 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 2647FD2686C for ; Thu, 30 Mar 2017 18:05:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 E4874D0B; Thu, 30 Mar 2017 18:05:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x233.google.com with SMTP id e75so117849466itd.1; Thu, 30 Mar 2017 11:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XoRghJYS7K8BIb3enCF6HDhQ6LEJzwmmamKLnPabm5Y=; b=Iuscrv5Bs6C51S+WDl+Tj/vWfDC51nu7SR30db/o9SVUjVwLw+oxBYdzy1u5gTAr2b zGksI8w994Rx7EjNHbPxxRAn0SmgD6Q59AsEStB/Vc//S/rfX5vTSycRmo7QQrhxWMTU JyBYswRfL6KQWT337DXNPXS79GY8oreQY5ZNDHyu86va6eag7xuK0ow83+GVyMVd2aXV JsIU5WZ2wXWZzwtDfY0fZk4gAtp4xE3E3xPTgsU9XJKP2WMVQ2HV88UNKh37mRDbu3Fi LNegLpHBNusnGtojfDnZdLnsKG+E8xg/zTXr6CqKvYWLv5PTv4cQ95mXHmHSQQLRtEGP jisg== 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; bh=XoRghJYS7K8BIb3enCF6HDhQ6LEJzwmmamKLnPabm5Y=; b=XPUxh18R5aKBy95x29mb2EnlQZesdwk3ODHTZZzSJlsYI+Nkc8IkAyBNvKs9zfLtoE IgVK9pylpw3XaDnSfGeEKv+yRqW8uSVH+KaN+apdsbctewayBT24zyK97KVmzV5DTzxX 75bqP8sndkDC+75IjOQKSw33O+zZa9TuJ6pTD9HV4SsG4jOqEYAkD/FN06BIEr33gBaf VeHlNKPXubXY86jwpgzbxOguAdkecjPrdsBCL4im3CwtF7XsLn7YwCASYj/OurY5FxEP epKliIK0ZxbAsj+ga1Fqt6DZttrHtTyVI4CJXF+x1l69YdqYfifiqYeMvbTIC+9oTpKD dfWg== X-Gm-Message-State: AFeK/H2rwZXCXPqv8MtkU5gClUKRVopc3KRyqE7+RO2A/KFXguOEoJyiQruXEP08PVbA40LMbV3QR1EvrmWJIw== X-Received: by 10.36.0.198 with SMTP id 189mr5652613ita.82.1490897048963; Thu, 30 Mar 2017 11:04:08 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.30.209 with HTTP; Thu, 30 Mar 2017 11:03:48 -0700 (PDT) In-Reply-To: References: <1612271904400.79526@mx5.roble.com> From: Ed Maste Date: Thu, 30 Mar 2017 14:03:48 -0400 X-Google-Sender-Auth: ntoTyoYffsMQeNDJNUcuUsLyQ3Y Message-ID: Subject: Re: /tmp/ecp.* created during kernel build? To: Dimitry Andric Cc: Roger Marquis , freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Thu, 30 Mar 2017 18:05:10 -0000 On 28 December 2016 at 06:31, Dimitry Andric wrote: > > This looks like a minor bug in elfcopy, when used as objcopy, > specifically when in combination with the --input-target binary flag: > > $ mkdir /tmp/foo > $ export TMPDIR=/tmp/foo > $ ls -l /tmp/foo/ > $ /usr/bin/objcopy --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 cloudabi32_vdso.o bar.o > $ ls -l /tmp/foo > total 12 > -rw-r--r-- 1 dim wheel 10198 2016-12-28 12:29:32 ecp.0xbNAi5i > > E.g. for some reason this does not clean up the temporary file. This should be fixed as of r316284 and will be MFCd before 11.1. From owner-freebsd-security@freebsd.org Fri Mar 31 21:18:44 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 E59F0D27438 for ; Fri, 31 Mar 2017 21:18:44 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 AF712941 for ; Fri, 31 Mar 2017 21:18:41 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: by mail-yb0-x22d.google.com with SMTP id l201so9440397ybf.0 for ; Fri, 31 Mar 2017 14:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SvLgkUiE2G+dgywUk6qn1NKuxCVm3dn6ku3rCC3EuUk=; b=DwcVMF+/WeKFbXu19bG0BOqQ/kw90hXtYzwSdQXarNWEE1j4HVTUAnwpZgSlri/+Tb yix14mD96NvkbQCyRmkTiDrUwck/UIppIBrmQHwe+Puc1FsOS05vj9o6rI/R2H1ZOXfR /MVHdeSnpXkfI2vbEltEFvg30p4XFnKjMhlVFfo5enDZeVa4ZryY4SxHLmzWOrHzSwi0 osAy3zMN2B1q5chLED5TuWeNLWxDAHqKo6vUpQimoPLjnb+Is7X7PEug65Sjd0X14XqK wJaCEaH71rnLUjtSkMj8CnoIE2vJbBWlfj5I9sEUFufdujtwmUCixCJZubzTpev252EX ArZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SvLgkUiE2G+dgywUk6qn1NKuxCVm3dn6ku3rCC3EuUk=; b=bPRN7+TD0Xwr0KvaXkNlua8zfeGRZHZ6C6nZEA67f2kGRI1ZJp8a7Na1lXg2Xiw5BX HwAp1TzQyHN8z1BAj+AbGEGBGHuNO/1F/kBBqD2WlV+2r6zlNXjzEm18OU2M42fvgGwg /jCdWN5H+1sv0SStnZ88VlC8VaIZ0A9jeeYHAsUxRE4c3xGHm1IJs8krpNeJrcVc68Pq q39W5IYJItRIAH5q4Ml1s2dKxl620fDnGFE1dQ8hkqR5ZiKX73AIW52oTfGI6/xGuTYe HtzHffSmrSs76qhdMBpkCEcR+wss1Owoc4kzAz9QywJo11QQL1IW2yrI6IuuQcDzO/zx G13g== X-Gm-Message-State: AFeK/H0cQpuO0ybFTUVIUcG9BnA3RNCPqZt7fmQ6oItPC+T16T3lEnqaSbQPm75Wy4AWFKIuRnUC3qn7AXv6Kg== X-Received: by 10.37.28.131 with SMTP id c125mr3810645ybc.37.1490995120694; Fri, 31 Mar 2017 14:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.244.134 with HTTP; Fri, 31 Mar 2017 14:18:40 -0700 (PDT) From: Luna Jernberg Date: Fri, 31 Mar 2017 23:18:40 +0200 Message-ID: Subject: pf and pfsense To: info@scalefactory.com, Henning Brauer , sales@netgate.com, info@pfsense.org, pfSense Support and Discussion Mailing List , deraadt@theos.com, FreeBSD-security@freebsd.org, me@zx23.net, info@nyi.net, support@nyi.net X-Mailman-Approved-At: Fri, 31 Mar 2017 21:26:02 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Fri, 31 Mar 2017 21:18:45 -0000 Hello, thanks for the help with stuff tonight guys :) Found good blogposts/github pages etc with all the info and mirror stuff i needed