Re: zfs native encryption best practices on RELENG13

[Peter Libassi]

> 23 apr. 2021 kl. 23:23 skrev Xin Li via freebsd-stable 
> :
> 
> On 4/23/21 13:53, mike tancsa wrote:
>> Starting to play around with RELENG_13 and wanted explore ZFS' built in
>> encryption.  Is there a best practices doc on how to do full disk
>> encryption anywhere thats not GELI based  ?  There are lots for 
>> GELI,
>> but nothing I could find for native OpenZFS encryption on FreeBSD
>> 
>> i.e box gets rebooted, enter in passphrase to allow it to boot kind of
>> thing from the boot loader prompt ?
> 
> I think loader do not support the native OpenZFS encryption yet.
> However, you can encrypt non-essential datasets on a boot pool (that is,
> if com.datto:encryption is "active" AND the bootfs dataset is not
> encrypted, you can still boot from it).
> 
> BTW instead of entering passphrase at loader prompt, if / is not
> encrypted, it's also possible to do something like
> https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.html
> .
> 
> Personally I'd probably go with GELI (or other kind of full disk
> encryption) regardless if OpenZFS's native encryption is used because my
> primary goal is to be able to just throw away bad disks when they are
> removed from production [1].  If the pool is not fully encrypted, there
> is always a chance that the sensitive data have landed some unencrypted
> datasets and never gets fully overwritten.
> 
> [1] Also keep in mind: https://xkcd.com/538/
> 
> Cheers,
> 
Yes, I’ve come to the same conclusion. This should be used on a data-zpool and 
not on the system-pool (zroot). Encryption is per dataset. Also if found that 
if the encrypted dataset is not mounted of some reason you will be writing to 
the parent unencrypted dataset.. At least it works for encrypted thumb_drive, i 
just posted this quick guide 
https://forums.freebsd.org/threads/freebsd-13-openzfs-encrypted-thumb-drive.80008/
 


/Peter
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M&O=D messed up dates and HASHID-only use make things extremely hard to find "in time order"

[Mark Millard via freebsd-stable]

Using an example to illustrate problems finding artifacts,
the problems not being limited to the example's specifics.

I have historically used https://artifact.ci.freebsd.org/snapshot/
to do build-less approximate bisecting (and other things). Such
use is very messed up since the git-related URL conventions
chosen were put in place. The below illustrates an example
of the mess for how things are currently presented.

https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M&O=D

lists ac845558f7b626d9a31b8f6dab686c45d39dc5a0/ as having
date/time 2021-Apr-10 18:43 .

But:

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/?C=M&O=D
lists:

powerpc/ and arm/ as having date/times 2021-Apr-10 18:54 and 2021-Apr-10 18:50
yet lists...
i386/ and arm64/ as having date/times 2021-Feb-19 19:00 and 2021-Feb-19 18:50 .

But it gets worse:

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/powerpc/?C=M&O=D

shows an empty directory. Same for:

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm/?C=M&O=D

By contrast,

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/?C=M&O=D

shows i386/ with date/time 2021-Apr-10 18:43 but

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/i386/?C=M&O=D

shows all the file dates as 2021-Feb-19 19:00 .

Going back to arm64/ I find a similar 2021-Feb-19 dating,
although 21021-Feb does show up in more places:

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm64/?C=M&O=D

shows aarch64/ with date/time 2021-Feb-19 18:50 and

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm64/aarch64/?C=M&O=D

shows the files also having the date/time 2021-Feb-19 18:50 .


In my view the choice to only use the hash-id for the commit
in the url is a usability mistake and the url prefix should
be of a form more like (for this example context):

https://artifact.ci.freebsd.org/snapshot/stable-13/n??-HASHID/

where the ?? is from:

git rev-list --first-parent --count

(as used elsewhere by FreeBSD).

(The HASHID might be just the 12 character prefix instead of the
whole hash-id as well.)

Such a convention would be more independent of dates possibly
being touched on the file server and would make time ordered
finding of things (such as for build-less approximate bisecting)
far more reasonable.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs native encryption best practices on RELENG13

[Xin Li via freebsd-stable]

On 4/23/21 13:53, mike tancsa wrote:
> Starting to play around with RELENG_13 and wanted explore ZFS' built in
> encryption.  Is there a best practices doc on how to do full disk
> encryption anywhere thats not GELI based  ?  There are lots for 
> GELI,
> but nothing I could find for native OpenZFS encryption on FreeBSD
> 
> i.e box gets rebooted, enter in passphrase to allow it to boot kind of
> thing from the boot loader prompt ?

I think loader do not support the native OpenZFS encryption yet.
However, you can encrypt non-essential datasets on a boot pool (that is,
if com.datto:encryption is "active" AND the bootfs dataset is not
encrypted, you can still boot from it).

BTW instead of entering passphrase at loader prompt, if / is not
encrypted, it's also possible to do something like
https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.html
.

Personally I'd probably go with GELI (or other kind of full disk
encryption) regardless if OpenZFS's native encryption is used because my
primary goal is to be able to just throw away bad disks when they are
removed from production [1].  If the pool is not fully encrypted, there
is always a chance that the sensitive data have landed some unencrypted
datasets and never gets fully overwritten.

[1] Also keep in mind: https://xkcd.com/538/

Cheers,



OpenPGP_signature
Description: OpenPGP digital signature

zfs native encryption best practices on RELENG13

[mike tancsa]

Starting to play around with RELENG_13 and wanted explore ZFS' built in
encryption.  Is there a best practices doc on how to do full disk
encryption anywhere thats not GELI based  ?  There are lots for 
GELI,
but nothing I could find for native OpenZFS encryption on FreeBSD

i.e box gets rebooted, enter in passphrase to allow it to boot kind of
thing from the boot loader prompt ?

    ---Mike


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is stable/13 going to start getting snapshot builds?

[Glen Barber]

On Fri, Apr 23, 2021 at 12:02:50PM -0700, Mark Millard via freebsd-stable wrote:
> Is stable/13 going to start getting snapshot builds?
> 
> (As stands, main , stable/12 , and stable/11 are getting them.)
> 

Yes.  I plan to have them available next week.  I fell behind on
upgrading the build machines.

Glen



signature.asc
Description: PGP signature

Is stable/13 going to start getting snapshot builds?

[Mark Millard via freebsd-stable]

Is stable/13 going to start getting snapshot builds?

(As stands, main , stable/12 , and stable/11 are getting them.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

etcupdate -p vs. root on zfs (and bectl use and such): no /usr/src/etc/master.passwd (for example)

[Mark Millard via freebsd-stable]

FYI: The default bsdinstall result for auto ZFS that I tried
has a separate zroot/usr/src dataset, which zfs mounts at
/usr/src .

UPDATING and such places indicate sequences like:
(think etcupdate where it lists mergemaster and ignore
-F and -Fi)


make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
[1]
 [3]
mergemaster -Fp [5]
NOTE: What /usr/src/etc/master.passwd here? (for example)
make installworld
mergemaster -Fi [4]
make delete-old [6]


etcupdate has the logic for handling -p:

if [ -n "$preworld" ]; then
# Build a limited tree that only contains files that are
# crucial to installworld.
for file in $PREWORLD_FILES; do
name=$(basename $file)
mkdir -p $1/etc >&3 2>&1 || return 1
cp -p $SRCDIR/$file $1/etc/$name || return 1
done

Note the "$SRCDIR/$file". But for a boot -s after
installing the kernel there is only zroot/ROOT/NAME
and no zroot/usr/src zfs mount so /usr/src/ is empty.

This leads to needing an additional step:

zfs mount zroot/usr/src

(The instructions do not deal with making / writable at this
stage either.)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"