reboot is exploitable

[Demetrio92]

On boot this setup sets the locking range 1 into an RW mode: https://github.com/fornellas/tcg_opal_rootfs/blob/master/initramfs-tools/scripts/init-premount/tcg_opal#L52

This persists across reboots. E.g. rebooting into a different system leaves the drive unencrypted.

Is there a way to create a reboot hook that would lock the range?

[fornellas]

You're free to do that if you want, though I bet it'd be quite challenging, because as soon as you lock the drive, all disk access will error out, and the only way I can think out of this, is to have systemd, immediately before calling reboot, start a ramdisk, pull sedutil into it, pivot_root to it, call sync, use sedutil to lock, then finally call reboot. Any other option I can think of would have potential to fail due to disk errors.

I suppose it is all a function on "how much safeguards are you happy with" situation. Arguably (though hard), it is possible to extract password from RAM when it is powered when using software encryption, and it is "technically" exploitable, but most people are happy with this level of security.

Perhaps it is worth documenting the characteristics of this particular solution, letting it clearer the scenarios that it should protect the data, the situations data is accessible, and the potential points of exploitation.

Personally, so long as I can poweroff my machine, and know it is encrypted, I'm perfectly happy with the solution, as I never carry it it a suspended state, so I'm essentially never exposed to a (somewhat sophisticated) reboot exploit (unless I'm robbed at gun point... in which case, my data would be the least of my concerns :-D).

[Demetrio92]

Yeah, looks like this is indeed more complex than I previously thought. Overall, it's just better to know. Eventually I will get around to writing a short summary and will submit a PR. Then we can close this ticket as a "known issue"

[tarruda]

the only way I can think out of this, is to have systemd, immediately before calling reboot, start a ramdisk, pull sedutil into it, pivot_root to it, call sync, use sedutil to lock, then finally call reboot. Any other option I can think of would have potential to fail due to disk errors.

Even that is still not perfect because it assumes an attacker would use a clean reboot. On a desktop PC, you can always press the "reset" button to restart immediately without cutting power to the SSDs

Best thing we can do is lock booting from external media in the UEFI and password protect it. Then an attacker would have to shutdown the PC in order to reset the UEFI and re-enable booting from external media.

[fornellas]

Even that is still not perfect because it assumes an attacker would use a clean reboot. On a desktop PC, you can always press the "reset" button to restart immediately without cutting power to the SSDs

IIRC BIOS will lock the driver again on reboot, I recall learning about some obscure option for that.