On 4/17/20, Ryan Moeller <freqlabs at freebsd.org>
wrote:>
>> On Apr 17, 2020, at 4:56 PM, Pete Wright <pete at 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?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)