I just tried to do a new install into a new Hyper-V VM (Windows 11 Host) off the 14.3 RELEASE bootonly ISO (downloaded June 11th, SHA256: ef9ed0815eb5f960f6725a8545382ff773806500b03f3f6ccd08ac717c80f85d).
After a successful install I create a new user. The new user's home is owned by root. What gives? Where did I go wrong? I also noticed that my DNS settings were not saved to resolv.conf, but instead to resolv.conf.bak
Details:
ISO: FreeBSD-14.3-RELEASE-amd64-bootonly.iso
Host Type: Windows 11 Hyper-V (version 10.0.26100.1882)
I tried rebooting the VM after installation and logging-in via ssh to double-check the issue. I was able to log-in just fine but I still have no permissions on my home folder
$ whoami
groditi
$ whoami | groups
groditi wheel
$ ls -al ~
total 1
drwxr-xr-x 2 root wheel 2 Jun 11 15:17 .
drwxr-xr-x 3 root wheel 3 Jun 11 15:17 ..
$ ls -al /home/
total 10
drwxr-xr-x 3 root wheel 3 Jun 11 15:17 .
drwxr-xr-x 20 root wheel 25 Jun 11 15:33 ..
drwxr-xr-x 2 root wheel 2 Jun 11 15:17 groditi
$ touch ~/test
touch: /home/groditi/test: Permission denied
I have a video screen-cap of the whole process above if anyone wants to seeit. put it on 2x speed as i was moving kind of slow trying to make sure i didn't do anything differently from the first time this happened
dataset for zroot/home/groditi is encrypted and it's not auto mounted
log in as root then check the output of zfs mount zroot/home/groditi
to unlock it you need to enter the key zfs load-key zroot/home/groditi
enter the passkey
then mount the zroot/home/groditi zfs mount zroot/home/groditi
after that you can login using the user groditi
Other option is to change the source for the encryption key via keylocation and keyformat variable for zroot/home/groditi
well i feel very silly right now. I’ve never used an encrypted home before so i didn't even think about this, but in retrospect it makes perfect sense. After all, I was never prompted for the password.
I've checked the handbook and I did not find anything regarding encrypted home directories. My objective here is that users should have low-friction storage that is not compromised if root is compromised and that root can't peek into. I thought this option would suffice, but thinking about it more it seems like we would have a chicken and egg problem because the fs would need to be mounted at boot time, otherwise it would not be available when a user uses SSH to access the system.
I guess my follow-up questions are,
what is the intended functionality of this option? I did not find anything in adduser(8)(). I found some information on a patch (https://reviews.freebsd.org/D47996) but am not sure about it's accuracy and it wasn't very informative.
How would you suggest I achieve the intended effect?
I suppose one way to achieve what I am looking for would be to have the encrypted file system mounted at the time of log-in, via a login script. The issue would then be how to unmount after the last session is ended for a particular user (if not done manually). I am also open to being told i am sniffing around the wrong bush.
If your root is compromised you will be unable to hide anything from him.
When the data is online (unlocked/mounted etc) it can be read or it's encryption keys can be obtained from the memory or captured during unlock by root or someone which have physical access to the server or hypervisor.
You need encryption to protect the information on the disk when it's offline, for example you need to replace a disk under warranty and you need to return this disk to the service if this disk is not SED then there's no easy way to destroy the data on it especially if the disk have bad sectors. Then you use GELI, bitlocker or some other encryption on the disk so it will make the recovery of the data a bit harder or worthless to spend time trying to decrypt it.
The other protection that you have is when you can't provide a physical security to the server or laptop and in case the disk is stolen or the entire device is stolen they can't be read easy on another machine.
When you don't have encryption on the entire disk using GELI and you are unable to enter the passphrase during boot, for example when the machine is VM your option is to use encrypted ZFS dataset which you can be unlocked after the machine boots or if you have dataset used to store a backups and you need those backups to be in encrypted state.
If your root is compromised you will be unable to hide anything from him.
When the data is online (unlocked/mounted etc) it can be read or it's encryption keys can be obtained from the memory or captured during unlock by root or someone which have physical access to the server or hypervisor.
Thank you for the reply. I guess I misunderstood the way user home encryption works, but it makes perfect sense that you can't further secure a mounted filesystem.
I'm familiar with using GELI on the zroot because that is what I do with the machines I have physical access to or that live on my workstation. I will look further into the available options and rethink how I plan to achieve my goals as it has become clear that what I had in mind was misguided. I am just looking to have good set of safeguards for a remote server where physical access is not available (for passphrase on boot) and, while theoretically physical access is secure, it doesn't hurt to consider the what-if scenarios. I will go back to the drawing board for now.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
