SecureBoot in TrueNAS SCALE and CORE; Vendor Keys First, MS keys Later

Problem/Justification
SecureBoot, aside from cases involving an encrypted boot partition, is the only way to ensure your system’s bootloader is free from rootkits. TrueNAS needs to support signing of their bootloaders by a custom, iX-Systems key, and one day expand this to a Microsoft key.

Impact
A basic implementation of SecureBoot means that users will try to boot the installer, be notified they need to install using a packaged key, and then add the key to their SecureBoot keyring. Then they can install TrueNAS as requested, which should also be using a similar key.

Users without SecureBoot fail to have any basis to trust the longterm security of any TrueNAS system. Virtual Machines or the host TrueNAS system could both be compromised and none be the wiser as the base image, being monitored for changes, could have a wise hacker circumvent any alarm or record system to notify users. This is an enterprise security level feature, otherwise TrueNAS is only for hobbyists.

User Story
I have had machines on my network compromised, resulting in my ‘unlocked’ TrueNAS NFS encryptions becoming locked without explanation. So if a device is in one location on my network, it’s inevitable that a lateral intrusion would have found a way to compromise my TrueNAS’s security. Something less fundamental, like a script injected at the system’s load, could be plausible as I’m not monitoring even system loads. However, if there was a more fundamental compromise, TrueNAS’s boot would have a rootkit installed, and I would again have no way to access or monitor this possible security vector. A user who has their bootloader compromised would have SecureBoot fail to load the system by the compromised bootloader failing the key signing check. They would then know they need to reinstall or rollback their TrueNAS system.

Without this, TrueNAS’s security is more fitting large enterprises who can monitor all sorts of the drive in use, and hobbyists, home personal users, or home lab users would be unable to see a compromise in the system.

I support the idea of a more secure boot process, but the approach you’re taking is not really the best approach for an open-source project. Better alternatives already exist, including:

TPM hardware is proprietary, so for hardware appliances you’d need to have an open specification alternative or use a software-based solution. In either case, you also need a trusted hardware device to detect the tampering you’re concerned about. These types of projects aren’t widespread, but they do exist.

If iXsystems does it in hardware, then you won’t be able to make use of such a feature without buying one of their appliances. Since a lot of enterprises believe (correctly or not) that systems inside their data centers are basically “safe” the cost of doing a hardware solution may not be cost-effective. A software-based solution with a trusted dongle is likely less expensive and makes the whole thing more optional. That would be my recommendation.

Now, the real question is: what’s the threat model you’re solving for? If you use a BIOS password and use passwords instead of keyfiles at boot, the system is pretty secure from a boot perspective outside of tampering with the physical hardware. If you’re concerned about untrusted software, unless TrueNAS is re-engineering to work from read-only media or include a HIDS that can detect undesirable software changes once the system has booted then I’m not sure I see how you can really validate anything.

For a HIDS, you don’t need Tripwire; even just having debsums check system packages would be a Pareto Principle solution. Since ZFS also computes checksums for everything, although some checksums optimize for speed rather than security, you almost have a bullt-in HIDS if you can trust that both the checksum verification tool and the list of checksums for key parts of the system software. But until you define what you trust, or figure out why you trust it, it’s just kicking the security can a few more feet down the road.

It may sound like I think boot security is a bad idea. I don’t. I think TrueNAS could be much better in this regard, but from a pragmatic point of view this is a hard problem to solve for unless you have a targeted use case. If you have hardware trust issues, you might want to think about buying security-hardened appliances from a company that sells hardware-centric secure boot systems and then install TrueNAS on that. If you’re concerned about post-boot security, then you either have to harden the OS or prevent post-boot access to the system. Neither is trivial, especially if you expect to be able to run TrueNAS tools like Docker, VMs, etc. Hardening often comes with a usability price tag, and so you have to define what trade-offs you want to make.

I think a good open-source, tamper-resistent boot loader is a decent idea, but the ability to securely leverage debsums, or provide access to a more HIDS-centric validation of ZFS checksums, would be a better idea for post-boot system security than tying into a Microsoft-signed TPM module. Give some thought to what attack vector you’re really trying to address here; chances are the solutions already exist, but may need some iXsystems support to enable support for them in the middleware.

1 Like