Re: OpenZFS Encryption: Docs, and re Metadata Leaks

> On 9. Jun 2021, at 04:17, grarpamp <grarpamp@gmail.com> wrote:
> 
> 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 this
>>> is zfs filesystem level encryption and not a replacement for our existing
>>> full-disk-encryption scheme that currently works?
>> 

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’m not aware of a good current doc for this. If anyone finds/writes
>> 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=frnLiXclAMo openzfs encryption
> https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view
> https://www.youtube.com/watch?v=kFuo5bDj8C0 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)