For those of your managing a fleet of Ubuntu devices, how are you handling encryption? I’ve been looking at the new TPM-backed FDE since it seems to check all my boxes, but it’s still experimental.
The only other option I see is just LUKS FDE. But how do you manage passphrases in that scenario without user simply overwriting your recovery passphrase?
Would love to hear from people actually managing device encrypting in production.
Hey James
Interestingly this is a topic that’s been getting a lot of discussion in my workplace too.
Personally I have a Kubuntu Focus M2 which comes with Encryption, although I have not ‘YET’ managed to pursuade my company to provision these for other Engineers in our org using Linux.
Anyway, there are some good docs on kfocus.org they have a Secure and Data Network page. Also I’ve tagged in @mike-mikowski CTO over there, as he might be able to provide additional insight.
I think Enterprise Security and Fleet management are important to address with clear unified message, as that is what will give decision makers the confidence they need.
Nice to know there are companies focusing on Linux hardware, software, and management as whole . I think that’s quite rare to see.
It could be a big shift for us, but seems like it could be an option.
Currently, we work with Dell for our Windows and Linux devices and we’re deploying Ubuntu (using subiquity autoinstall) then managing with Puppet.
The biggest challenge is not so much encrypting the device, but managing the LUKS passphrases.
One of our biggest requirements for encryption is having a recovery passphrase known only to us in IT. I’m trying to avoid having to manually configure and record each passphrase.
I know it’s already possible for RHEL, but we’re using Ubuntu. I’d rather not have to switch.
Thanks Rick for the shout out!
@jamesps in LUKS, one can have multiple slots for each partition, and we use that for YubiKeys and chain encryption, and we have pretty evolved scripts to automate that. It should be fairly trivial to adjust them for fleets. Here’s an overview of what we implement.
The TPM-based keys look promising, but at this time, a bit scary too. If I’m reading a recent article correctly, in 22.04 TPM support is buggy and was broken for over a month with the HWE kernel(1). Of course, if we were to support it, we would not allow a broken kernel like that to be deployed through our extensive validation procedures, shown here.
I hope that helps. I’ve pinged @arraybolt3 , who is a MOTU, a primary contributor to the Focus code base (among many others!), and implemented the BTRFS over LUKs configuration in Kubuntu 24.04 LTS. He may have more to add.
(1) See silvenga dot com /posts/tpm-luks-unlock/. Sorry, Discourse limits me to 2 links.
o/ Some extra input since Mike pinged me:
how do you manage passphrases in that scenario without user simply overwriting your recovery passphrase?
If you mean “how do you add more than one passphrase to a drive”, LUKS supports this natively as Mike mentioned. There are multiple “key slots” on a LUKS-encrypted drive. Each slot corresponds to one passphrase. You can program your master admin passphrase into one slot and the user’s personal passphrase into a second slot, and be good to go. You can install the same master admin passphrase on all machines. Each user has to remember their own passphrase (or have a hardware security device like a Yubikey that is properly bound to the disk), but the admin needs to only know the master passphrase. About the only time I can see this not working is if IT needs to gain remote access to an encrypted machine without the user having to explicitly decrypt the drive. Even then though there are solutions like Intel AMT that may allow working around that limitation.
If you mean “can the user be prevented from deleting the admin key”, well, not really. The passphrase data is stored on the disk, if the user overwrites it then the passphrase won’t work. Really any mechanism for FDE that stores key info on the disk will have this issue though, and even if you avoid that, a malicious user who wanted to hide their activity could always just wipe the disk. So I don’t think this is really an attack scenario you can defend against with technical means. Instead you’d want rules like “anyone who locks IT out of their machine is suspended for a week and will be fired if they do it twice.” (Or something like that - obviously in practice you may want to be even more strict but you get what I mean.)
Personally just from a security standpoint, I don’t think TPM-based disk encryption is probably a good idea in general. The reason is because it makes your encryption security only as good as the security of the lock screen. What I mean by that is, if you use TPM-based encryption, the system will automatically decrypt itself on startup, and then present the user with the lock screen. At that point, there’s no need for an attacker to break the encryption. All they have to do is figure out an exploit in the lock screen and boom, they’re in. For a developer machine that may be running SSH or other server software, this risk grows exponentially since now there are other potential points of entry a malicious user can attack. They just have to steal the laptop, attach it to their network, power it on, and then find an RCE in whatever exposed servers there are. If they’re smart and block the ability for the machine to get automatic software updates (via a firewall), they can just wait for a new RCE exploit to be found in whatever server software the machine happens to be running, and then break in that way. The encryption prevents trivial ways of getting in like booting from a USB stick or placing the drive in another computer, but it doesn’t prevent exploiting the target system’s software stack.
Compare this to passphrase-based encryption. You no longer are depending on the security of the software to keep the data safe, you’re depending on the security of a cryptographic algorithm. Traditionally, cryptographic algorithms have had WAY less holes in them than modern-day software, and the holes that do exist are of no practical value to an attacker. No matter what kind of arcane tricks an attacker may use to run arbitrary code on the machine or whatever, they can’t get in without knowing the encryption key, and the encryption key isn’t anywhere on the machine. Your data is safe.
LUKS is, to my awareness, filesystem-agnostic, so whether you use ext4, BTRFS, XFS, etc., it should all work the same. I run BTRFS+LUKS at my workplace on a Kubuntu 24.04 machine, and it works great.
Hope this is helpful!