root pool zfs encryption ?

[johndoedoe]

Hello
is there a way to encrypt the root pool on truenas ?
this is really strange to put the encryption keys of encrpyted data partition in a clear partition.
I can type the password in my ilo4 card remote console when reboot.

thanks

 

[Cloudified]

You have to do when you create the pool. I don't think there's a way to turn it on at the pool level after it's created.

 

[winnielinnie]

Do you mean the top-level root dataset?

Yes, each and every dataset, no matter how high up the tier or down the nest, can either be encrypted or plain. You can have all children below the top-level root dataset inherit the same encryption properties, or use their own encryption properties, or even granularly have some encrypted and others plain.

The reason that the user keystring is stored on the plain boot-pool is so that the top-level root dataset can be unlocked automatically at bootup, since TrueNAS needs access to the System Dataset (.system). However, if you re-located the System Dataset to another pool (or even the boot-pool)[1], then you may change the encryption property of the top-level root dataset from "keystring" to "passphrase", in which nothing will be stored in the plain. It's up to you to remember the passphrase and manually unlock the dataset(s).

[1] As long as the System Dataset does not exist within a particular pool, then that pool's top-level root dataset can be encrypted and manually locked/unlocked with a passphrase, as it has no need to be automatically unlocked at bootup (and can safely be manually locked in a live system), since the System Dataset is accessible from the other pool or boot-pool.

 

[Arwen]

I think @johndoedoe means encrypting the boot pool, with the TrueNAS software on it.

If you use a passphrase and encrypt your entire data pool, every reboot will require you to type in the passphrase. And no keystring is stored on your boot pool.

However, their is no method to encrypt the boot pool. This is by design, because using a passphrase eliminates any risk to your data pool.

---

There have been questions about encrypting the boot pool before. Some people don't understand that the boot pool does not contain much information, just general configuration details. TrueNAS, both CORE & SCALE, are appliance software designed for NAS usages. Thus, with a saved configuration, the boot pool is completely replaceable on loss.

If a user needs extreme protections, (perhaps due to distrust of their government), TrueNAS is probably not for them.

Their are lots of computer security that can be applied:
- BIOS passwords
- SED, (Self Encrypting Disk drives), passwords
- Grub passwords
- Software level disk encryption
- Software level file encryption
- And of course, ZFS dataset & zVol encryption

The one caveat to many of these types of security & encryption methods, is that they do ZERO for live servers. Meaning if the server is up and running, and someone gets in to the server, at rest security or encryption does not help at all.

 

[winnielinnie]

The one caveat to many of these types of security & encryption methods, is that they do ZERO for live servers. Meaning if the server is up and running, and someone gets in to the server, at rest security or encryption does not help at all.

[sarcasm]
Wow. You are COMPLETELY misinformed and ignorant about IT security.

I've researched, in-depth, plenty of movies and video games, and as long as you configure the proper anti-anti-security software, then you can thwart most viruses and hoodie-wearing hackers (who usually work in poorly lit rooms with RGB keyboards as their only light source).

The crucial factor is to make sure that the hacker's green circuits don't overtake your neutral circuits by using the industry established "counter backtrace" that reverses their hacking with patented defensive red circuits.

The nice thing about harnessing these security measures is that they should work on any system, regardless of the OS or filesystem. To have ZFS encryption on top of that is nice, yet not necessary, since your anti-anti-security mini anti-virus circuit robots should suffice to keep your server and data safe. And yes, unlike what @Arwen is naively implying, this works especially well on live servers that are up and running.

@Arwen: I suggest you read up and refresh yourself on real-world IT security.
[/sarcasm]

[notsarcasm]
FORUM POST CHANGELOG:

• CVE Update 2022-0128-0060: Added the proper tags

[/notsarcasm]

 

[Arwen]

@winnielinnie - I suggest a last line to your post to make it clear to non-native English speakers that you are being sarcastic.

When I have a sarcastic line or 2, I tend to use sarcasm tags:

[sarcasm]You post was very enlightening and absolutely true![/sarcasm]

 

[Ericloewe]

Hey, I consider myself a native speaker and you had me going there, I was slowly reaching for my moderator hat even...

 

[winnielinnie]

I thought the animated GIF I made would serve as a glaring sarcasm tag.

 

[Arwen]

Except some of us have animation disabled.

 

[johndoedoe]

Thanks all,
keep calm and have a deep breast ;)

I work in cyber security and for me there are no inforrmation that are not important. Config file are not "THE" data but are an important source of information for a hacker who stole a drive for example. And yes a passphrase can protect the disk for direct access but i will feel more safe if all my drives are fully encrypted, included system drive.

I have other servers running on top of zfs file system and there are no problem to encrypt the full system drive before installing it via a live cd. The boot loader is not encrypted but the system ask me a password on boot. This is not a problem for me. I prefere that.

For the moment i hesitate between installing my own nas directly from scratch with a fully encrypted file system or keeping true nas. The advantage of truenas is the confort and the fully packaged solution way but my priority is the security.

@winnielinnie I mean the system pool so if i understand it correctly the boot-pool. When i install a fully encrypted zfs os i have a separate boot-pool with just the boot loader wich ask me the decryption password before launching the operating system

@Arwen the 0 risk doesn't exist and configuration file are precious information for any hacker who access to it.
The main purpose of encryption is to protect data from robber.

These are indeed good practices:

- BIOS passwords => obviously this is realy important. but no protection about disk stoling
- SED, (Self Encrypting Disk drives), passwords => Dependent on a proprietary solution. My goal with ZFS is to reduce this dependency and increase the reliability of my system.
- Grub passwords => only protect the boot not from disk stoling
- Software level disk encryption => yes this is precisely what i want with zfs :)
- Software level file encryption => this is a complementary protection but not applicable in this case.
- And of course, ZFS dataset & zVol encryption => Software level disk encryption

If there are no solution i will have to re-analyse my risk level to evaluate wich kind of information the server will contain to define if truenas security level is ok for my appliication or if i have to build my own storage server. For me the impossiblity of encrypting the system pool is a huge vulnerability. Disk or server robbery even happend in datacenter. Find the cost/time/security level balance is not easy.

 

[Ericloewe]

If you want that scenario, you’re going to have to hack it together yourself. Or maybe virtualize TrueNAS (careful, there are hidden landmines) and encrypt the install from there.

 

[Arwen]

@johndoedoe - You can use SED with ZFS pool / dataset encryption, to get both. But, for TrueNAS you would need a BIOS that will prompt you for the SED password(s). (Other OSes, like Linux, can have a small "/boot" partition on an un-SED disk, which can prompt for the SED encrypted disk's passwords.)

What I meant by "Software level disk encryption" is the old FreeBSD Geli disk partition encryption, which used to be the way FreeNAS got ZFS pool encryption. In theory a custom built NAS could use both Geli partiton encryption & ZFS pool / dataset encryption. Combined with SED, you have have triple level of encryption .

But as @Ericloewe pointed out, what you ask for is not possible with any version of FreeNAS or TrueNAS. (Except, by external means not part of FreeNAS / TrueNAS. Which Ericloewe pointed out one way.)

 

[johndoedoe]

Ok
I have to check where i want to put the security level cursor.
between reinstall a minimal machine with minimal services and maximal security and using truenas :)
thanks for your answers

 

[sn0ot]

The one caveat to many of these types of security & encryption methods, is that they do ZERO for live servers. Meaning if the server is up and running, and someone gets in to the server, at rest security or encryption does not help at all.

I agree that the list you provided are techniques for data-at-rest however it is worth mentioning that dataset encryption can be used to lock a dataset while the system is live and thus prevent reading or writing into the dataset. This is handy for when you have a dataset that you access seldom (for example storing tax returns forms or other legal paperwork). This is a home storage example, there are plenty more for corporate applications as well.

A slight inconvenience is you need to log into the GUI and lock and unlock it manually but if it is something you access infrequently you can keep that dataset secure and have some peace of mind if your system is compromised.

 

[Ericloewe]

Sure, but how does encryption on the boot pool bebedouro that scenario?

 

[sn0ot]

Sure, but how does encryption on the boot pool bebedouro that scenario?

I am referring to dataset encryption within an existing storage pool. In regards to the post I replied to, if a newbie stumbles upon it, the post implies that dataset encryption can do nothing for a live system security. I wanted to clarify (for future noobs like me) that dataset encryption can secure your data on a life system if the user is okay with manually unlocking it before read/writing to it.

As for boot pool. I understand @johndoedoe 's paranoia from a cybersecurity perspective. It is probably a good time to make it clear that what he probably wants to secure is the System Dataset which stores juicy metadata such as debugging core files, encryption keys for encrypted pools, and Samba4 metadata such as the user and group cache and share level permissions. Without it, the pool is not recoverable.

As for the system, @Arwen already mentioned

the boot pool does not contain much information, just general configuration details

and this is true because the user, or an attacker, can just pull the latest ISO and (re)install it onto a server, insert the drives and try to "Import existing pool" (which is impossible as long as the system dataset cannot be read). So from that perspective, why encrypt the boot if it can just be downloaded.

If @johndoedoe wants to encrypt the boot drive so that the machine is not physically tampered with behind his back or hide the pointer to where his encrypted system dataset resides, then I would suggest simply having a small NVMe drive containing the boot partition and encrypting the boot partition by having the bootloader decrypt it (which would require intervention with passphrase or getting creating with keys during boot). Or do drive encryption of the NVMe that stores the boot info, and decrypt the entire drive with a bootloader that supports full disk encryption. The bootloader doesn't know - or care - that FreeBSD is the OS and TrueNas is the application.

 

[Skrenes]

Sorry to bring this up again, but I was wondering about the credentials information. They contain keys to change domain names (which means they could change the mx server for my email and hijack email/2FA) and private keys that give access to remote backup servers and cloud infrastructure. Why can't this at least be stored on an encrypted (passkey) dataset? It seems this is reason enough to encrypt the boot pool.

Edit: It should be noted that the System Dataset does NOT contain these keys. They're stored on /data which is on the boot pool.

 

[sretalla]

I wanted to clarify (for future noobs like me) that dataset encryption can secure your data on a life system if the user is okay with manually unlocking it before read/writing to it.

I think that's not giving the full picture either...

You need to be prepared to:

Lock the dataset as soon as you're finished with it to close the exposure.

Understand that while the dataset is unlocked, it's not protected. A suitably motivated attacker who already gained some access to the system could set some kind of watcher to wait for the dataset to be unlocked and grab the contents while it is.