gpg: Signature made Wed Jun 8 21:34:04 2022 UTC
gpg: using DSA key 0E4236CB52951E14536066222099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hello,
On Wed, Jun 08, 2022 at 04:40:55PM -0400, Ian Kelling wrote:
> I skimmed, but agree with your analysis.
>
> I have a systemd service which, on reboot, adds a luks key stored on
> the encrypted disk to the unencrypted initrd, and on boot, removes
> it.
That's an interesting idea!
So, there is a time window just as your VM is shutting down where
the initrd contains a working LUKS key. If an attacker was able to
prevent your VM from booting they could grab that key out of your
initrd and boot a copy of your block device with their own initrd,
right?
Still it reduces the time span when you are vulnerable…
Perhaps with a remote secrets server it could be improved by storing
a signature of the initrd and kernel command line as well. Then only
an unmodified initrd being booted as expected (no init=/bin/bash)
could request the LUKS key. If something else requested it, the
secrets server would refuse and it would fall back to manual
passphrase input on console (or over ssh-in-initrd).
I suppose the method of updating the signature of the initrd in the
secrets server would itself require a passphrase to be typed as
otherwise the attacker could register their own initrd signature
there.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
"SCSI is usually fixed by remembering that it needs three terminations: One at
each end of the chain. And the goat." — Andrew McDonald
