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.