Date: Tue, 8 Jun 2021 22:40:45 -0400 From: grarpamp <grarpamp@gmail.com> To: freebsd-stable@freebsd.org Subject: OpenZFS Encryption: Docs, and re Metadata Leaks Message-ID: <CAD2Ti29ajEtYmSo0ugEoPAMRaNxks1wQb0jy87YGaKGHpE%2BNzQ@mail.gmail.com> In-Reply-To: <CAD2Ti28FA-=moyEVr-NkRQVRdr84=P2LzWpHd-E42SpTeODC5w@mail.gmail.com> References: <CAD2Ti28FA-=moyEVr-NkRQVRdr84=P2LzWpHd-E42SpTeODC5w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 <freqlabs@freebsd.org> wrote: > >> On Apr 17, 2020, at 4:56 PM, Pete Wright <pete@nomadlogic.org> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti29ajEtYmSo0ugEoPAMRaNxks1wQb0jy87YGaKGHpE%2BNzQ>