Ubuntu developer here. I don't think that's fair. The OS, as shipped today, isn't designed with this threat model in mind. It's correct to say that for TPM-based LUKS unlock to be safe, the initramfs must not allow the user to take control of it. But that's a new requirement introduced when the user modified their system to configure TPM-based LUKS unlock. This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!

That's not to say that an improvement can't be made as we move towards a future where TPM+LUKS might be the norm - just that you can't retrospectively claim fault on an OS that doesn't claim to support that.

> This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!

And it still is perfectly reasonable behavior. Any distribution that decides (perhaps as a consequence of this) that on any boot process abnormality the default response is to enter an immediate reboot loop would be called crazy.

Sorry but Clevis (similarly to bitlocker without PIN) is security theatre.

I think it is fair to say that OS configuration to fix this should be required.

I agree with the logic that by default the OS is doing the right thing without any changes to support this model.

> it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!

It’s still looks perfectly reasonable, just PCR should be fed with some value before that, maybe a hash of initramfs file? It seems to be reasonable as at this moment the state of the operating system differs from the one properly booted, which seems to fit the idea of secure boot.

This way it would be possible to still unlock LUKS with a pass phrase but not access TPM keys locked for configuration when initramfs shell is not running.

This is one of those designs where you skim a description and already know it’s going to break in a million different ways.

I still don't understand why people believe that you can have any expectation in these ludicrous scenarios.

Like, you are dropping a general purpose computer into the middle of Russia, expect to be able to command it remotely to do anything, even remotely update it and reboot it; and at the same time never bother to come check it up in person or even have minimum chassis intrussion detection. Do people really expect this to work just by adding some TPM craziness?

The article is just connecting a keyboard sniffer/simulator but it would have been as easy to do anything to the network traffic, SSD, motherboard/CPU JTAGs, RTC, etc.

Well, it's sorta possible. Just not with the TPM, and not in general purpose computing applications.

Games consoles are super locked down, to prevent piracy, and some modern consoles have gone years without a successful hack, despite being in the physical possession of the attacker. The iphone's activation lock is extremely hard to bypass, and even cops and border guards struggle to extract users' data.

Simply buy your PC from your operating system vendor directly, and forego options like being able to replace components and being able to install your own software, allowing the memory and PCI bus to be encrypted. Add some cloud backup features so the device can wipe itself at the drop of a hat without losing your data. After that, just have your OS vendor produce perfect code with no exploits, and you're secure!

Simple! /s

100% this is sketch. I was thinking if this was a supported security model you shouldn't be able to take control without disabling the TPM.

But it isn't so not the OSes problem.