[Security] System Dataset and encryption of pools

matulano

Dabbler
Joined
Dec 26, 2021
Messages
10
Hi

I currently have TrueNAS Core installed on a Mirror of 2 SSD called freenas-boot (default name when I installed FreeNAS). I have 2 Pools (let's call them PoolA and PoolB) which have been created with encryption turned on with 'Key' encryption.

My System-Dataset is currently stored on PoolB.

I want to secure my server further by making sure that even if someone were to steal my whole physical server they couldn't access the data. To do that I thought of switching the 'Key' based encryption (which auto decrypts the pools on boot) and enable 'Passphrase', so that I have to manually unlock the pools by hand upon reboot with the passphrase set.

I currently cannot set passphrase encryption on 'PoolB' as it's the location that has the 'System Dataset' on it, but I can do so on 'PoolA'. So I was thinking of moving the 'System Dataset' onto the 'freenas-boot' pool. (technically not really a pool, right?)

But I don't fully understand a few things about the encryption and wasn't able to find out by reading the manual.
  1. Is it true, that someone could access the data on both pools if I'm using 'Key' based encryption and they would steal the whole server?
  2. Is it true that currently the only way to decrypt 'PoolA' is with the backup of the keyfiles if 'PoolB' (which stores the 'System Dataset') were to catastrophically fail?
  3. Is it true that point 2. would also be true if it was on the 'freenas-boot' pool and that were to catastrophically fail?
  4. Is it true that the 'System Dataset' containing the Keys is not encrypted, as they could read them in plain text?
  5. Is it true that someone would be able to access the data of 'PoolB' if they were able to get their hands on all the drives of that pool, since the 'System Dataset' lives on that pool and containes the keys? (assuming the key files are stored in plain as the 'System Dataset' is not encrypted as per question 4.)
  6. Is it true that it would generally be a better idea to always store the 'System Dataset' on the 'freenas-boot' pool? Assuming question 4. & 5. are true?
  7. It it true that a passphrase is generally the more secure way to encrypting the pool, even if that means giving up some quality of live due to having to decrypt the pool upon reboot?
  8. Is it true that the WebGUI admin password can be reset if someone has access to the whole server and accessing the console on server level? I'm not sure if you have to login first
So, from what I could gather in my case it would be best to move the 'System Dataset' to the 'freenas-boot' pool and then set passphrases on PoolA and PoolB to have maximum security. This would obviously require me the safely store the passphrases somewhere safe, like a password manager and maybe somewhere offline in an actual physical safe. Am I good to go with this solution?

Thanks for the help in advance!
 

Redcoat

MVP
Joined
Feb 18, 2014
Messages
2,924
So, from what I could gather in my case it would be best to move the 'System Dataset' to the 'freenas-boot' pool and then set passphrases on PoolA and PoolB to have maximum security. This would obviously require me the safely store the passphrases somewhere safe, like a password manager and maybe somewhere offline in an actual physical safe. Am I good to go with this solution?

I do not use encryption - but I have followed the writings of a couple of forum members who have written an lot on this subject, including creating resources. I suggest that you use the search function for "encryption" and by @PhiloEpisteme and @winnielinnie and read their contributions.

I believe you will find answers to your questions that allow you to conclude that your solution is a good one for your case, but you may also see some drawbacks from their discussions to balance your thinking.

Good luck with whatever you decide.
 
Joined
Oct 22, 2019
Messages
3,589
Is it true, that someone could access the data on both pools if I'm using 'Key' based encryption and they would steal the whole server?
If they grab the server, then they just power on the system (like you would) and they automatically have access to everything. The datasets automatically unlock with the key(s) stored on the boot-pool.


Is it true that currently the only way to decrypt 'PoolA' is with the backup of the keyfiles if 'PoolB' (which stores the 'System Dataset') were to catastrophically fail?
The key file(s) are on the boot-pool. However, you should always make a backup of them, since if/when your boot devices fail (or something else happens where you lose the key files), your data is gone forever.

I don't know why the documentation still gets it wrong: The key file(s) are not on the System Dataset. If they were, how would it even be possible to automatically decrypt the encrypted System Dataset during bootup?


Is it true that point 2. would also be true if it was on the 'freenas-boot' pool and that were to catastrophically fail?
See above.


Is it true that the 'System Dataset' containing the Keys is not encrypted, as they could read them in plain text?
See above.


Is it true that someone would be able to access the data of 'PoolB' if they were able to get their hands on all the drives of that pool, since the 'System Dataset' lives on that pool and containes the keys? (assuming the key files are stored in plain as the 'System Dataset' is not encrypted as per question 4.)
See above.


Is it true that it would generally be a better idea to always store the 'System Dataset' on the 'freenas-boot' pool? Assuming question 4. & 5. are true?
That depends if you also want the System Dataset (.system) to be encrypted. If you don't care about this, and the boot-pool is comprised of SSDs, then it makes more sense to locate the System Dataset to your boot-pool. This will also lessen the frequent writes to your main data pools.

The System Dataset contains logs and some information that can reveal things about the server. Depends how paranoid you are.


It it true that a passphrase is generally the more secure way to encrypting the pool, even if that means giving up some quality of life due to having to decrypt the pool upon reboot?
Personally, I prefer passphrase(s) because there are no key files that you need to backup or keep away from others. There's no risk of losing your only means of accessing your data. As long as you don't "lose your mind" and you remember your passphrase, then you're all set. :wink:

The only caveat is that you cannot have the top-level root dataset (which happens to adopt the pool's name) protected with a passphrase, if you want the pool to also house the System Dataset. This is just the way TrueNAS does things.

You can still place the System Dataset on a pool with passphrase protection! :cool: You must remember that ZFS doesn't encrypt pools: it encrypts datasets. So just have the top-level root dataset protected with a key, and then the rest of the datasets can be passphrase protected. I like to use my "pseudo-roots" method to keep things clean and organized. When you boot the system, the top-level root dataset will automatically unlock, and thus the System Dataset (also encrypted) will automatically unlock and be immediately available. You will still need to manually unlock the other datasets with your passphrase.

Perhaps one day in the future, ZFS encryption will make use of "slots", just like Linux does with LUKS. This means you can have multiple passphrases and keys to unlock a dataset; rather than having to decide "one or the other".


Is it true that the WebGUI admin password can be reset if someone has access to the whole server and accessing the console on server level? I'm not sure if you have to login first
Yes, but more importantly, if someone has physical possession of your server, it's their server now. They can do whatever they want with it. They can even install TrueNAS or a Linux distro of their choice. They can pop your boot-pool SSDs into another computer, import it, and then access the contents under the /data/ directory. A strong root user password won't stop a smart and determined malicious party. However, passphrase-protected datasets will be inaccessible.
 
Last edited:

matulano

Dabbler
Joined
Dec 26, 2021
Messages
10
I do not use encryption - but I have followed the writings of a couple of forum members who have written an lot on this subject, including creating resources. I suggest that you use the search function for "encryption" and by @PhiloEpisteme and @winnielinnie and read their contributions.

I believe you will find answers to your questions that allow you to conclude that your solution is a good one for your case, but you may also see some drawbacks from their discussions to balance your thinking.

Good luck with whatever you decide.

Thanks for the hints, I was able to find some good threads discussing the fundmanetals and caveats regarding encryption. Allthough I have to say some of the information seems to be outdated and not applicable anymore, since most of the talk about FreeNAS which used GELI for encryption, but it sure answered some questions.

If they grab the server, then they just power on the system (like you would) and they automatically have access to everything. The datasets automatically unlock with the key(s) stored on the boot-pool.

The key file(s) are on the boot-pool. However, you should always make a backup of them, since if/when your boot devices fail (or something else happens where you lose the key files), your data is gone forever.

I don't know why the documentation still gets it wrong: The key file(s) are not on the System Dataset. If they were, how would it even be possible to automatically decrypt the encrypted System Dataset during bootup?

That is something that actually confused me as the documentation really does state the keys would also be stored inside there. I was just assuming there will be an unencrypted dataset on the encrypted pool that stores the keys, which is why I actually asked question 4. and 5.

That depends if you also want the System Dataset (.system) to be encrypted. If you don't care about this, and the boot-pool is comprised of SSDs, then it makes more sense to locate the System Dataset to your boot-pool. This will also lessen the frequent writes to your main data pools.

The System Dataset contains logs and some information that can reveal things about the server. Depends how paranoid you are.

That is a good point to take into cosnideration now that I know, they keys are not stored on whatever pool the 'System Dataset' is on but always on the boot pool anyway. Personally, I'm not to worries about those data being acessible, but I'll surely have to look more into it now, to see exactly what data is on the 'System Dataset'. Since the boot pool consist of 2 mirrored SSD, I'm not too concerned about wear.

Personally, I prefer passphrase(s) because there are no key files that you need to backup or keep away from others. There's no risk of losing your only means of accessing your data. As long as you don't "lose your mind" and you remember your passphrase, then you're all set. :wink:

The only caveat is that you cannot have the top-level root dataset (which happens to adopt the pool's name) protected with a passphrase, if you want the pool to also house the System Dataset. This is just the way TrueNAS does things.

You can still place the System Dataset on a pool with passphrase protection! :cool: You must remember that ZFS doesn't encrypt pools: it encrypts datasets. So just have the top-level root dataset protected with a key, and then the rest of the datasets can be passphrase protected. I like to use my "pseudo-roots" method to keep things clean and organized. When you boot the system, the top-level root dataset will automatically unlock, and thus the System Dataset (also encrypted) will automatically unlock and be immediately available. You will still need to manually unlock the other datasets with your passphrase.

I will probably go ahead and move my 'System Dataset' to the pool pool and switch to Passphrase protection for the pools. The solution you posted actually seem kinda slick and unifying the best of both world if you aim to keep your 'System Dataset' encrypted as well. Since i'm concernd about something having access to the whole server, I will not bother encrypting the 'System Dataset' though.

Yes, but more importantly, if someone has physical possession of your server, it's their server now. They can do whatever they want with it. They can even install TrueNAS or a Linux distro of their choice. They can pop your boot-pool SSDs into another computer, import it, and then access the contents under the /data/ directory. A strong root user password won't stop a smart and determined malicious party. However, passphrase-protected datasets will be inaccessible.

This is exactly why I want to switch to passphrase. Thanks a lot for the explanation and insights! As a follow up question:

Am I right in the assumption that encrypted pools in TrueNAS with ZFS native encryption do not suffer the complicated steps for replacing failed drives within like they did with GELI encryption? Meaning I can just replace the drive in the GUI and that's it, no need to regenerate keys or anything? My passphrase will still work for the new drive aas the datasets are encrypted now and not the drives themself anymore?
 
Last edited:
Joined
Oct 22, 2019
Messages
3,589
Am I right in the assumption that encrypted pools in TrueNAS with ZFS native encryption do suffer the complicated steps for replacing failed drives within like they did with GELI encryption?
I think you meant to write "do not suffer the complicated steps". :wink:

Meaning I can just replace the drive in the GUI and that's it, no need to regenerate keys or anything? My passphrase will still work for the new drive as the datasets are encrypted now and not the drives themself anymore?
That's exactly correct.

GELI is FreeBSD-only (on the block devices). While native ZFS encryption is universal, per dataset. Any system that supports ZFS (since the merger of code between the different projects, such as OpenZFS and ZoL), will be able to use native ZFS encryption without doing anything fancy.
 

matulano

Dabbler
Joined
Dec 26, 2021
Messages
10
I think you meant to write "do not suffer the complicated steps". :wink:

Indeed, edited the post :D

That's exactly correct.

GELI is FreeBSD-only (on the block devices). While native ZFS encryption is universal, per dataset. Any system that supports ZFS (since the merger of code between the different projects, such as OpenZFS and ZoL), will be able to use native ZFS encryption without doing anything fancy.

Perfect, so I understood that correctly. Thanks for the all the informations.
 
Top