No FDE on OS Drives?!

[throwaway3295032]

I've been unable to find any information on how to implement FDE on OS drives. Some threads have discussed some thinly veiled excuses as to why it's not existent ('you might lose your password' and 'a thief could just memory dump the running device to obtain crypto keys' (sure, lets see a junkie do that).

Is there any logical reason why FDE is not implemented? Aside from leveraging FDE on virtual machines, I cannot see any way to mitigate threat models of a full server being stolen. Even in the context of a data center, I'm sure not many would bat an eye at an authorised technician removing a random server.

Is there something I'm missing?

 

[Ericloewe]

Is there any logical reason why FDE is not implemented?

The threat model is not a realistic concern and it's extra work for something that is fairly brittle (disk encryption for data disks always had sharp edges at it was). There's very little that could be considered sensitive on the boot pool, if you keep the system off it. Email passwords for sending mail, maybe AD credentials, and not much more comes to mind.

Also, you'd need to provide the passphrase directly on the local console for this to work, or maybe have some sort of trampoline that then loads the real OS. One is a massive pain for admins, the other is a massive pain for the devs.

What would be far more interesting is a targeted encryption of these small bits of sensitive data, that can be handled by the standard API/WebGUI - similar to existing encryption of data, to satisfy the paranoid among us while still keeping things mostly practical. This could even easily leverage the new ZFS native encryption support, by moving all sensitive data to a dedicated dataset. This actually sounds like a great feature request, if someone can list the sensitive data that should receive this treatment (optionally).

 

[sretalla]

Is there something I'm missing?

Buy iX hardware with TrueNAS Enterprise and use KIMP.

 

[Chris Moore]

Buy iX hardware with TrueNAS Enterprise and use KIMP.

What is that?

 

[winnielinnie]

Email passwords for sending mail, maybe AD credentials, and not much more comes to mind.

Email password is stored directly on the boot device, not the .system dataset?

 

[sretalla]

What is that?

Well, the docs: https://www.truenas.com/docs/core/storage/pools/storageencryption/

point to this to explain: https://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html

Sadly, it's an Enterprise-only feature.

/core/uireference/system/kmip/

Also, this might be an example of a service able to be used as KIMP: https://aws.amazon.com/kms/

 

[danb35]

Email password is stored directly on the boot device, not the .system dataset?

The live config database isn't on the .system dataset--backups are, but the working config isn't. That also likely means that the user passwords are stored there, though they may well be hashed or otherwise not in cleartext.

Edit: This isn't that hard to see; the config file is a SQLite database. So if I browse through it, the system_email table seems to have the email configuration. And in there, the password is at least obfuscated--I can't tell exactly how it's encoded, but it's not simply written in plain text. But I'd expect it can't be a one-way hash, since the system needs to know the plain-text password in order to log in to the email server.

 

[Ericloewe]

Email password is stored directly on the boot device, not the .system dataset?

I haven't checked, but it wouldn't surprise me.

 

[throwaway3295032]

> The threat model is not a realistic concern and it's extra work

Just because something is not a realistic threat model for you doesn't mean it's not a realistic threat model for other people. You cannot comprehensively understand or assert all environments in which TrueNAS instances are running and this narrative is frankly an immature and negligent approach to security. I also imagine the lack of FDE on boot drives raises issues with compliance in certain environments also.

> something that is fairly brittle

I can't see any situations where OS drive encryption has been brittle, having used OS encryption for ~6 years. Are you able to provide evidence of your claim?

> Email password is stored directly on the boot device, not the .system dataset?

This almost certainly has to be the case. As danb said, even if it's stored 'encrypted' it has to be reversible in some form in order for the system to make use of it at boot. But to be clear, an attacker who has physical access to your server for prolonged periods is able to backdoor it in order to steal credentials, etc.

FDE doesn't prevent this on it's own (secure boot can help) but it does increase complexity to an attacker pretty substantially - I could easily inject an entry into authorized_keys on some random unencrypted drive. I'd have far more trouble modifying a kernel, or physical hardware, in order to backdoor post-boot processes, or steal crypto keys out of warm memory.

 

[throwaway3295032]

> Also, you'd need to provide the passphrase directly on the local console for this to work, or maybe have some sort of trampoline that then loads the real OS. One is a massive pain for admins, the other is a massive pain for the devs.

Sure, so don't make it a default? Maybe there are people who care more about security than you, who would prefer to have a system explicitly fail than deal with the risk of having an unencrypted root filesystem. If it's a real issue due to physical distance or similar, then there's always remote boot interfaces.

 

[danb35]

Just because something is not a realistic threat model for you

Whatever. Neither Eric, I, nor you makes this decision. If you think it should be there, file a ticket (link is in the page header) and see what the devs say. You won't be the first, and probably won't be the last.

 

[Ericloewe]

The devs have already dismissed an easy evil maid attack against the boot pool as not a concern, and that was far easier than getting away with the whole server and the fix was damned easy (import using the pool GUID instead of the pool name), so I don't expect this to gain a lot of traction.
I do, however, like the idea of an encrypted dataset for sensitive data (i.e. The passwords that need to be stored in plaintext) and it seems like a useful compromise.