From nobody Wed Jun 9 02:40:45 2021 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E96405D7C83 for ; Wed, 9 Jun 2021 02:40:49 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G0BDd1gqdz4bMX for ; Wed, 9 Jun 2021 02:40:48 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id d13so13358720edt.5 for ; Tue, 08 Jun 2021 19:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=XMz/ctFFOslYKSagDhvbOyZMath3L+jPylUq1Q8or7I=; b=tNhwFul8h6yXa/ZpDcEV/oNerRChUvXw4pRJfZtm/CvattoEKBddxRf3uKbUgugMpa XDTZRqqJcbJ2Ty0zPlQRaunKVbWw9NPWwlUQ5h2VeZiMEoMAcRev/VhUPCivF8M5leyJ +oQeroQOvD5F4FZego1a4TEiCCLc8UEoXmnbo2CgbaSsbhBjbF+aXtmGkFoV5a55tQ8r m6fDHE9w6Oj+x4AvaFkmo4DODpMAnPcpdtwAycOVdhqNdxRbCT+gb9Zw2HtSlkINX5C+ zgZBfLfjy3uqZh0Ns+w4TK5bpp5k0EwG/4cHDG5IryqzBh2Advsb0XjJUr+mWkuP3hjw Gh4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=XMz/ctFFOslYKSagDhvbOyZMath3L+jPylUq1Q8or7I=; b=Cw9BQeke6l8JsrrpxDx+XRGasCzLM7zRn0/FT1R5UROuX+pAKuFP7JcD1JaixdrQ5G qPbyCcjyYHGJV2d3F8/KV/zRBl7HRmxj3Sij0TWyf81pCvcy4N/BxWeapvgoYLv9C8bI NmCKAeUfFIW5e2SBBNFUZo4cHOdhe0vhwUpfpvcyWBH/aqE7OYB/WOLW/vruM1uIyL5z jUh9U1XupUxDaC8Vgk95nhTs2RYjnUXZRLt5GyLf1fyLgqwlxrK6BonoUoXiH5FCntkK /LC4iwwkm4of7zXQ3DY9auO8DQvTfeNVzaOHnjDctdkBXbzHomCCMBrqHRf1Yrfc/45I lEMg== X-Gm-Message-State: AOAM533Tnv6UEkXtDIlsKbwMAM79q2FHIajbhAL/7+DtnUwp7sBOXgje 5ebXPenh2OZA1d0VoguoJ3ydCMTIOg1z/xMDChVJRkx4chAhmjf8 X-Google-Smtp-Source: ABdhPJyKd+ORPB2hagWcEIcv6fS+LsR/Yiu+IGCSjuV9NCwDB3OcZgvW5kUVsS2HbI86TbwD2Jn9lu8va8EedF/gLBc= X-Received: by 2002:aa7:ca1a:: with SMTP id y26mr28292186eds.314.1623206446267; Tue, 08 Jun 2021 19:40:46 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Received: by 2002:ab4:a201:0:0:0:0:0 with HTTP; Tue, 8 Jun 2021 19:40:45 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Tue, 8 Jun 2021 22:40:45 -0400 Message-ID: Subject: OpenZFS Encryption: Docs, and re Metadata Leaks To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4G0BDd1gqdz4bMX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=tNhwFul8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::533:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::533:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-stable] X-ThisMailContainsUnwantedMimeParts: N [Leaving a copy here for people seeking doc links from April. Rest of thread may go elsewhere, perhaps fs, don't know. Cheers.] On 4/17/20, Ryan Moeller wrote: > >> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: >> >> On 4/17/20 11:35 AM, Ryan Moeller wrote: >>> OpenZFS brings many exciting features to FreeBSD, including: >>> * native encryption >> Is there a good doc reference on available for using this? I believe th= is >> is zfs filesystem level encryption and not a replacement for our existin= g >> full-disk-encryption scheme that currently works? > > I=E2=80=99m not aware of a good current doc for this. If anyone finds/wri= tes > something, please post it! > There are some old resources you can find with a quick search that do a > pretty good job of covering the basic ideas, but I think the exact syntax= of > commands may be slightly changed in the final implementation. > > The encryption is performed at a filesystem level (per-dataset). You could find some initial doc and video about zfs encryption on openzfs.org and youtube, and in some commit logs. Therein was mentioned... People are needed to volunteer to expand documentation on the zfs crypto subject further in some document committed to openzfs repo since users and orgs will want to know it when considering use. Volunteers are also sought by openzfs to review the crypto itself. Maybe there was already some central place made with further current documentation about the zfs encryption topics since then? https://www.youtube.com/watch?v=3DfrnLiXclAMo openzfs encryption https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view https://www.youtube.com/watch?v=3DkFuo5bDj8C0 openzfs encryption cloud https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view It's dataset level, so GELI or GBDE etc are needed for full coverage, perhaps even those two may not have yet received much or formal review either, so there is always good volunteer opportunity there to start with review of a potentially simpler cryptosystem like those. zfs list, dataset snapshot names properties etc not covered. zfs history not covered, many sensitive strings will end up in there, including cutpaste password typos into commandline, usernames, timestamps, etc... and no tool exist to scrub overwrite history extents with random data, and no option exists to turn keeping of 'user initiated events' or 'long format' off, and ultimately no option exists to tell zpool create to disable history keeping from the very start entirely. So maybe users have to zero disks and pools along with it just to scrub that. zfs also exposes these variety of path and device names, timestamps, etc in cleartext on disk structures in various places, including configuration cachefile... Some of those could could be NULLed or dummied with new zpool create options for more security restricted use cases. There are other meta things and tools left exposed such as potentially any plaintext meta in send/recv. Another big metadata leak for environments and users that ship, sell, embed, clone, distribute, fileshare, and backup, their raw disks pools and usbs around to untrusted third parties... is that zfs also puts hostnames and UUID type of unique static meta and identifying things in cleartext on disk. zfs thus needs options to allow users to set and use a NULL, or generic dummy default, or random string, or chosen, "hostname" for those from the very first zpool create command. Most applications users use, including zfs, can today consider ways in which metadata leaks could be removed entirely, or at least optioned out for use under high security restricted environments modes. That could even involve considering trading off some extra features not actually required for a basic mode of functionality of the app. (cc's for fyi inclusion about leaks, and as lists still haven't been configured to support discreet bcc for that purpose, which would also maintain nice headers for thread following. Gmail breaks threads. zfsonlinux topicbox peole can't subscribe without javabloatbroken website, so someone could forward this there. Drop non-relevant cc's from further replies. Parent thread from freebsd current and stable lists was Subject: OpenZFS port updated)