From nobody Wed Jun 09 09:11:25 2021 X-Original-To: freebsd-current@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 1FA5211C924F for ; Wed, 9 Jun 2021 09:11:28 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G0LvM5ZDgz3hKZ; Wed, 9 Jun 2021 09:11:27 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 4aebdaf0; Wed, 9 Jun 2021 09:11:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=wRzKOWvWCeSXd9 Bjb7vQKEwozwU=; b=r1+syxYxolRtU/y3yXtYvBfqkFLisuqtcOybDc1FsBFTSg M/hQoeChUMOrqdrh0Q/JH+NlXPcaJiPCfDT6tZddNcoE2mrXSW/19gVAiQZycNCg 5mx9hFu6s1VJ0doKXRWkf+Qh7Rp6G/Mf9TiKV3Ygeh7c6XeaLXaw30+MD8vFfL2/ LEgslu3FANrofSW4RS87VWtY/VYa62PD6WPWYTIvt6c+6+Q1QQzqi5UC2NFiW7f/ XqVPQUNudwlwJU9dCyEBUkux6qQg+bCJLqCorUd5pOVU/1/yaMsonD3U8ugPtntg emLlUmleqwudsyDuIrSefWS8DW6KMO5X9WbBBJLw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=iLEzt53r N8pqBiDzWJAblRvMsOS3yWTlQEe9QYauOe/GDfgtQSh1kSsRBFGxn4VjyvEDFiAf IttFLPBq/J7TX2macE0UbNXvzXmVZYiRs13cU1x+1m2hHNdozoezd2xuWGQhmozw 9MM3NPstH1OasiwA8OstwfVQBjCp454hUpmu+fzTUzNVeuV6Xfs45EkOkCnsNdKM pyA79sSOznBsYxZcMBBLIEIvbu47hMUTMgYRD7dR/9/puFOnO0DWC7CBHMNUJCGt tq5FrD4S0jqWlJduhFSUAiVspEDWkL1qok1eJkV+fWeavLo0F0/095c2sLtlg6Gc ZRWgoe8TMysvZg== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 3a6583b3 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Wed, 9 Jun 2021 09:11:25 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-0946C98E-D715-49EB-8D66-E0B2D8A5C401 Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: OpenZFS Encryption: Docs, and re Metadata Leaks From: Michael Gmelin In-Reply-To: Date: Wed, 9 Jun 2021 11:11:25 +0200 Cc: freebsd-current@freebsd.org Message-Id: <2D204488-C9F5-40FF-A119-6B91D0750F24@grem.de> References: To: grarpamp X-Mailer: iPhone Mail (18E212) X-Rspamd-Queue-Id: 4G0LvM5ZDgz3hKZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail-0946C98E-D715-49EB-8D66-E0B2D8A5C401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 9. Jun 2021, at 04:17, grarpamp wrote: >=20 > =EF=BB=BFOn 4/17/20, Ryan Moeller wrote: >>=20 >>>> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: >>>=20 >>> 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? >>=20 I found this to be a useful starting point: https://blog.heckel.io/2017/01/08/zfs-encryption-openzfs-zfs-on-linux/#What-= s-encrypted -m >> 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. >>=20 >> The encryption is performed at a filesystem level (per-dataset). >=20 >=20 > You could find some initial doc and video about zfs encryption > on openzfs.org and youtube, and in some commit logs. > Therein was mentioned... >=20 > 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. >=20 > Maybe there was already some central place made with further > current documentation about the zfs encryption topics since then? >=20 > 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 >=20 > 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. >=20 > zfs list, dataset snapshot names properties etc not covered. >=20 > 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. >=20 > 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. >=20 > There are other meta things and tools left exposed > such as potentially any plaintext meta in send/recv. >=20 > 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. >=20 > 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. >=20 >=20 >=20 > (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)