Language Selection

English French German Italian Portuguese Spanish

LUKS mermaids of remote unlock

Filed under
Security

Recently, I’ve browsed several how-to’s regarding the possibility of unlocking a LUKS root volume remotely using an SSH connection. For reference, the first of its kind is the one for Debian, published at Coulmann.de. Some of these how-to’s were posted to forums and mailing-lists and received many thankful comments from sysadmins wondering how to make their encrypted secure setup also easy to administrate.

The problem with their approach is simple: they asked how to fix their setup, but forgot to ask what they’re trying to protect. Having your root filesystem on an encrypted disk doesn’t protect you from remote exploitation or credential leaks. It just protects you from the risk of someone being able to access your machine locally and steal your data, or just steal the whole machine altogether. Now, if I were an attacker having access to your hardware locally,

I could easily setup a trap for you in less than 5 minutes:




More in Tux Machines

Leftovers: Gaming

Leftovers: Software

today's howtos

ACPI, kernels and contracts with firmware

This ends up being a pain in the neck in the x86 world, but it could be much worse. Way back in 2008 I wrote something about why the Linux kernel reports itself to firmware as "Windows" but refuses to identify itself as Linux. The short version is that "Linux" doesn't actually identify the behaviour of the kernel in a meaningful way. "Linux" doesn't tell you whether the kernel can deal with buffers being passed when the spec says it should be a package. "Linux" doesn't tell you whether the OS knows how to deal with an HPET. "Linux" doesn't tell you whether the OS can reinitialise graphics hardware. Read more