* systemd-cryptsetup gained support for unlocking LUKS2 volumes using
TPM2 hardware, as well as FIDO2 security tokens (in addition to the
pre-existing support for PKCS#11 security tokens).
I'm gonna try it out once my Solo V2 arrives.
Granted, in case of theft, the computer will boot up if nothing is done to it. But in the case of a "user" computer where no services are listening, the risk is relatively low. In order to get access to the decrypted disk contents you'd have to exploit some vulnerability in Linux and / or the login manager.
Some people consider it more convenient to just boot the thing, take the protection against casual loss of confidentiality and accept the risk they might face from determined attackers.
This is a tradeoff. A "random user"[0] might be put off by having to type in a password every time they boot up their PC and forego disk encryption altogether. This approach is a net improvement over an unencrypted drive, even if it's not perfect.
As usual in matters of security, threat modelling is important. Who are you and who are your defending againts?
Are you some high(-enough)-profile target with potential access to interesting infrastructure or data? You may want to not rely on only this approach. As siblings have said, some kind of supplemental factor could be better. Say a challenge-response factor based on a Yubikey. Also, if the thief is determined, they may attempt to steal the laptop while it's running. You may want to look into desktops if that's the case. And not plug them into a UPS, of course.
But are you just a random Joe whose threat model is that you have some photos you wouldn't like seen, maybe some personal documents, but not much more? Then you need "just enough protection". If someone steals your PC, it's likely for the PC itself and not for the data it carries. They may want to check what's on it, see if there's anything juicy. Might even try "password" or something to unlock it. But they will probably not spend too much time trying to brute force Linux (or Windows for that matter).
> Almost every machine has some services exposed
How often is this the case on a random user's machine?
Even on my Windows machine I've only got SMB and RDP listening. Which I've manually enabled.
On my Arch Linux machine, which is my actual work machine, only SSH listens. Which I've manually installed and enabled. On an ubuntu desktop 20.10 install, there's no SSH server installed. There are no daemons listening on the external interface.
I guess you may attempt some attack against the DHCP client if you really want to get into that machine. I also suppose the pipe wrench exploit can still be tried.
> and there are also hardware-based attacks possible
Don't you think that if someone's going to invest the time and ressources to conduct such an attack against your PC you might be the kind of target who should be aware that's a possibility? Which brings us back to the point above about threat-modelling.
---
[0] I realize we're talking about LUKS and Linux, so maybe the "random user" isn't all that random. But maybe it's a "mom's computer" on which someone installed Ubuntu or something.
People need to be aware this can happen when using it and should remember to add a password key to their luks container.
Though I'm fairly certain that Linux will forego this and just assumes you known what you're doing.
Yes, even the documentation for the systemd feature implies generating the recovery key is a separate optional step.
That has been possible (without TPM) since about 2009: Shameless plug: https://www.recompile.se/mandos