From nobody Wed Jun 09 02:15:12 2021 X-Original-To: freebsd-fs@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 0EC5E5D5642; Wed, 9 Jun 2021 02:15:16 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4G09g66f7Dz4XJl; Wed, 9 Jun 2021 02:15:14 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ej1-x62b.google.com with SMTP id c10so35804673eja.11; Tue, 08 Jun 2021 19:15:14 -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:cc :content-transfer-encoding; bh=SZ1dE8ixmghv2pEIbDI43g6Vfem+rSPYolxq56gSUqE=; b=EAUO8zgelGixBONyPxXHfZ8KgtKcDirgKvZlef6yC4mHI97YNsieQkNHMwi5e199sn MYL1yGCVhzEGyoaBEil1x0pwNST5qcmytfgR4WEcD4heSL5wtJ/7q0Er/9RQHLMwhcb9 LX5BUUbfe5lTxCtutfvx/HPGXAJH8FvMamYbiQjimVfq3dARH561kfKod8yk5e+kwkKf wPfTdfUY6KaKsYilidBsOUQYeeXtfA/x+M000vTB/46lDYu/V1ir3Ctsl23d73hzAo9A DNkJtlYd/BjisHuvUH6SS6V1/52nCbEh5TjObPsFvuNczbzQCRD6bdAg8F4SnPtzccJe vgNA== 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:cc :content-transfer-encoding; bh=SZ1dE8ixmghv2pEIbDI43g6Vfem+rSPYolxq56gSUqE=; b=df2X6eB59Ua8fGhULE96+DdPY4oxaPDRotrhsTSUgZDgmsdlMvFDS/ySDngE8GIWvU DgSaMx78cnO5+73ZHxdyfuHuUWOWy0My/hvuZKiCWtJrs6Y6IsN3QgnzLhWKXvZJ6VCz 7SYQo8vqyH5lUbpGiiF/RqVb7ZVngyaKQnvQgyYXiZkz3l0EIaQMYhqvjya5igh94Jyw KhvcCslrrtWEyOJozkuEtN8U3IATlLb35/pj3J7WrX6C4M/ji8NYJvWx2cOApXHQsjS/ MekSSPqUI+1qPueNGpH4BCzTozZ2Hm1bP6iMSoeEPqMeHCaMjxUZfB2r4j8nHUiXNny/ HdhA== X-Gm-Message-State: AOAM530hLT5IlpW6kogD9fsv6RK+iYZc7jHTiv+f+3i9aCgxT14+t6vA 7khGEvKQb686JogATDta1P6o7BoVI4sOtuX+CxPhedd3M/IWewaSnm0= X-Google-Smtp-Source: ABdhPJwZVjvK/s1m5T8GAKUOvEQlEzt/HqVuKlJyQvra+fUJuazREb2FjzjIrDilG+lf/1ht0qv/wZyjN9SbX6Hrtec= X-Received: by 2002:a17:906:757:: with SMTP id z23mr25450260ejb.537.1623204912927; Tue, 08 Jun 2021 19:15:12 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Received: by 2002:ab4:a201:0:0:0:0:0 with HTTP; Tue, 8 Jun 2021 19:15:12 -0700 (PDT) From: grarpamp Date: Tue, 8 Jun 2021 22:15:12 -0400 Message-ID: Subject: OpenZFS Encryption: Docs, and re Metadata Leaks To: freebsd-fs@freebsd.org, zfs-discuss@list.zfsonlinux.org Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4G09g66f7Dz4XJl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=EAUO8zge; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62b:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62b:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-fs,freebsd-stable,freebsd-current,freebsd-questions,freebsd-security]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N 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)