/boot/entropy and zfs bootpool

[ericx]

When installing a new FreeBSD 11.0 with zfs root, the installer creates 2 zfs pools and puts the contents of /boot in zfs:bootpool/boot. /boot is a symlink pointing to /bootpool/boot

Normal boot process then does not mount bootpool (nice little security extra there) so the /boot symlink points to a nonexistent dir.

/etc/defaults/rc.conf sets: entropy_boot_file="/boot/entropy" which is used by /etc/rc.d/random so it fails with the error "no such file or directory."

my question:
Better to set entropy_boot_file to something like /var/db/entropy or just touch /bootpool/boot/entropy sometime when bootpool is not mounted?

Is this a bug?

 

[ericx]

OK..

Creating /bootpool/boot/entropy appears to work quite nicely. The file is masked if one mounts zfs:bootpool (jftr: zpool import -f bootpool and the unmount: zpool export -f bootpool); but presumably this is an unusual occurrence and the loss of entropy will not be a problem(?).

Also in order to address the lack of Google hits for the presence of FreeBSD /bootpool, it is notable that late loading of any kernel modules will also fail:

• mounting file system types fdescfs, procfs, linprocfs, tmpfs, etc. require kernel modules which would normally load if the /boot/kernel were mounted and read'able will fail with Operation not supported by device.
• setting linux_enable in either /etc/rc.conf or /etc/rc.conf.d/abi would "normally" result in a kldload of several linux modules which will also fail.
• other examples?

The solution is to load the modules early in boot via /boot/loader.conf. So note which modules you need, mount zfs:bootpool, and edit loader.conf. e.g. something like:

##############################################################
###  Filesystem and related modules  #########################
##############################################################

cd9660_load="YES"       # ISO 9660 filesystem
fdescfs_load="YES"       # Filedescriptors filesystem
linprocfs_load="YES"       # Linux compatibility process filesystem
#linsysfs_load="NO"       # Linux compatibility system filesystem
#msdosfs_load="NO"       # FAT-12/16/32
#nfsclient_load="NO"       # NFS client
nfsserver_load="YES"       # NFS server
procfs_load="YES"       # Process filesystem
tmpfs_load="YES"       # temp filesystem
zfs_load="YES"           # ZFS

##############################################################
###  Emulation modules  ######################################
##############################################################

linux_load="YES"       # Linux emulation
linux64_load="YES"       # Linux emulation

##############################################################
###  Networking modules    #####################################
##############################################################

ipfw_load="YES"           # Firewall

 

[Vossy]

The solution is to load the modules early in boot via /boot/loader.conf. So note which modules you need, mount zfs:bootpool, and edit loader.conf. e.g. something like:

Hi Ericx, i've just installed FreeBSD 11.00 with MBR (Bios) to solve a different issue and noticed i am having a similar problem here with bootpool.

I'm still kinda new to BSD, and i just wondering how to solve this problem.

When i try things like freebsd-update fetch .. i get a 'cannot identify running kernel'.

once i zpool import -f bootpool things seem to work.

i'm a little confused.

 

[ericx]

When i try things like freebsd-update fetch .. i get a 'cannot identify running kernel'.

once i zpool import -f bootpool things seem to work.

I think you got it.

By not mounting the kernel pool, it makes it that much more difficult for an intruder to edit any of the files. In broad terms, since the kernel and it's modules are loaded into memory at boot you can get away with hiding them away during normal operation by just not mounting the pool (in some sense, the kernel and modules load before the file systems are mounted). However, there are tasks where you still need to touch files ( freebsd-update being an obvious example). In which case you have to mount bootpool at least long enough to do whatever.

Like most things "security," it's fussy and makes life more difficult. I don't know how much more robust it makes the system's security overall (very worth asking a security expert). A separate boot partition is common practice on a lot of Linux set ups. If you feel this is more trouble than it's worth, you can change the pool settings so that it always mounts.

 

[Maxnix]

Normal boot process then does not mount bootpool (nice little security extra there) so the /boot symlink points to a nonexistent dir.

Hi Ericx, i've just installed FreeBSD 11.00 with MBR (Bios) to solve a different issue and noticed i am having a similar problem here with bootpool.

I'm still kinda new to BSD, and i just wondering how to solve this problem.

When i try things like freebsd-update fetch .. i get a 'cannot identify running kernel'.

once i zpool import -f bootpool things seem to work.

i'm a little confused.

This happens regularly with an encrypted zroot, or as a bug on MBR installtions. That's not a security measure¹.
As a workaround add this to /boot/loader.conf:

zpool_cache_load="YES"
zpool_cache_type="/boot/zfs/zpool.cache"
zpool_cache_name="/boot/zfs/zpool.cache"

References:
Thread 42980
PR 212258

¹Leaving apart the fact that this would be a case of "security through obscurity", it would be totally useless: an exported bootpool will surely prevent an attacker loading modules present in the kernel directory, but this can be done only as root. If an attacker already have root access to load kernel modules, how much time will he need to just import the pool before proceding?