I don't see any encryption bypass there. Encrypted partition stays encrypted.

The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem.

I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least.

You'd still be at risk because of this flaw, because the root shell would allow sniffing the key from a secure session. Ideally, attempts to brute force the user account should prevent further attempts by rebooting or refusing further interactive input.

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least.

I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted"

If your organisation is large enough to start losing track of entire servers, and yet small enough you can't adopt effective organisational controls to prevent such losses, even mediocre encryption might give you some peace of mind - and it lets you avoid reporting data breaches, as the lost data was 'encrypted'.

The threat vector mitigated by Clevis[1] is someone with physical access (e.g. an insider) removing the server from the data center and being able to access its data.

[1] https://github.com/latchset/clevis