ZFS /boot/ folder in encrypted ZFS in FreeBSD 11

[john2011]

I installed FreeBSD 11 with encrypted ZFS from the official live CD. After using the system fine for some days, I changed something in /boot/loader.conf then can not boot. I searched and the way to recover is to boot from live CD and type:

# cd /tmp/
# mkdir mounted
# geli attach /dev/ada0p3
# zpool import -f -R /tmp/mounted zroot

it worked, and here is what ZFS look like

# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot               5.64G   223G    96K  /tmp/mounted/zroot
zroot/ROOT          4.05G   223G    96K  none
zroot/ROOT/default  4.05G   223G  4.05G  /tmp/mounted
zroot/tmp            124K   223G   124K  /tmp/mounted/tmp
zroot/usr           1.58G   223G    96K  /tmp/mounted/usr
zroot/usr/home       373M   223G   373M  /tmp/mounted/usr/home
zroot/usr/ports      642M   223G   642M  /tmp/mounted/usr/ports
zroot/usr/src        608M   223G   608M  /tmp/mounted/usr/src
zroot/var           1020K   223G    96K  /tmp/mounted/var
zroot/var/audit       96K   223G    96K  /tmp/mounted/var/audit
zroot/var/crash       96K   223G    96K  /tmp/mounted/var/crash
zroot/var/log        512K   223G   512K  /tmp/mounted/var/log
zroot/var/mail       120K   223G   120K  /tmp/mounted/var/mail
zroot/var/tmp        100K   223G   100K  /tmp/mounted/var/tmp

However, I can not find /boot/loader.conf ! The following directories are empty (other than other ZFS mount points):

# ls /tmp/mounted/
tmp usr var zroot
# ls /tmp/mounted/zroot/
#

I believe I also tried to zfs mount zroot/ROOT somewhere else but also found nothing there.

other ZFS partitions all appear fine, for example:

# ls /tmp/mounted/usr/ports/
.arcconfig
.gitattributes
.gitignore
CHANGES
...

I have hence reinstalled system, however it is scary to know we have to re-install the system any time if messing up something in /boot/loader.conf .

Where can I find /boot/loader.conf when mounting from live CD?

 

[ShelLuser]

Disclaimer: I never bothered myself with this because I don't see any advantages with regards to security here. Think about it: if your system gets compromised from the outside then your attackers will have filesystem access anyway, just like any other running process on your system. And if your physical machine falls into the wrong hands there's little you got protected as well, unless... Unless you actually need to provide a password before everything boots.

Having that out of the way.

The answer is really very simple: the /boot directory was never part of the main ZFS pool in the first place. Think about it: it would need to decrypt the filesystem to access it, and it can't do that without proper keys. So how to read the keys and other required information if those were encrypted? Easy: by keeping that part unencrypted.

What you should have done is check the disk for any other partition(s) and access those, instead of solely focusing yourself on the ZFS pool.

But even more important: you should have made yourself familiar with the way this security scheme works. You don't gain any security advantages by merely applying some fancy new feature without understanding what it actually does. Fancy features don't make a secure system, an administrator with a secure mindset does.

So yeah... your answer: sysctl kern.disks followed by using # gpart show and optionally a mount operation.

 

[tobik@]

However, I can not find /boot/loader.conf ! The following directories are empty (other than other ZFS mount points):

zroot/ROOT/default has the canmount=noauto property set so is not mounted when you zpool import, but you can do it manually with zfs mount zroot/ROOT/default

 

[ANOKNUSA]

I don't know if this is still true (it would appear so), but as ShelLuser pointed out, prior to 11.0-RELEASE when you uses the encryption option with the automatic ZFS install, /boot was given its own separate pool called bootpool. This is because until 11.0 the bootloader could not decrypt an encrypted filesystem, so /boot could not reside on one. If that is still the case, then you need to import bootpool instead of zroot.

it is scary to know we have to re-install the system any time if messing up something in /boot/loader.conf .

No offense, but diving into the water without knowing how deep it is will always be risky.

 

[john2011]

Thank tokik@ so much! That immediately resolved the problem. I should have looked into zfs mount that slice more closely. So this ZFS encrypted method can be a reliable solution for us now.

So this /boot/ folder is indeed encrypted in FreeBSD 11, right? I think I read somewhere that some developer tried to squeeze the gptzfsboot loader and geli decryption into the 512KB boot partition.

There are plenty of situations this full disk encryption is extremely valuable. Coorporations need to make sure their intellectual property won't leak in case an employee's laptop is lost, and many other similar situations.

I have used FreeBSD for quite a while so trusted there must be a solution I just need to learn it, and hopefully other people who ends up in this situation can google this solution easily.

 

[ShelLuser]

There are plenty of situations this full disk encryption is extremely valuable. Coorporations need to make sure their intellectual property won't leak in case an employee's laptop is lost, and many other similar situations.

Sorry if I come over as pushy but I hate to see people put too much faith into something than it's actually worth. You're right here of course but once again: unless your system actually requires a password for you to type in during the boot phase itself then there's no additional security here at all. Having a separate /boot or not doesn't change that.

If your laptop gets lost then people can power it on and they're in. If you set a bios password they can swap your disks, and since you yourself performed steps to access your data using a live CD, so can others. Most of all: it doesn't stop anyone from hacking a running system, because a running system obviously has access to the filesystem(s) in the first place. Otherwise it wouldn't run.

At best it could prevent people from directly accessing your device nodes (say /dev/ada0p1). But that can also be achieved by using # sysctl kern.securelevel=1 or keeping the right permissions. But how useful is that considering that applying a rootkit is a much easier way to gain access than mucking with device nodes.

Encrypting your disks does not make your system safer by definition.

 

[john2011]

unless your system actually requires a password for you to type in during the boot phase itself then there's no additional security here at all.

The system does require a password to type in during the boot phase. Other people certainly can not power it on and in. I don't quite understand what you say.

Maybe you didn't know the standard FreeBSD 11 installation allows one to do full disk encryption except the 512KB boot loader that's unencrypted? Previous versions allowed one to do something similar except /boot/ was unencrypted.

Indeed I can mount from live CD but note I had to issue the geli command which demands a passphrase. Without that the disk is a brick.