Re: GRUB & crypto? (& generally, more info on undocumented modules?)

[Jordan Uggla]

On Sun, Dec 21, 2014 at 5:46 AM, John Lane <address@hidden> wrote:
> On 20/12/14 23:16, Diagon wrote:
>>>> I use a keyfile to avoid the duplicate passphrase entry issue. The
>>>> keyfile is on the USB stick. It's also inside the initramfs so that the
>>>> booting kernel can also unlock the disk. It's safe because the initramfs
>>>> is on an encrypted volume.
>> John - does this mean that in your case, you never have to enter a 
>> passphrase?  That is, it appears the keyfile on the USB opens your /boot, 
>> and then the keyfile in the initramfs opens your root.
> that's right.
>>
>> I am a little leery of putting the keyfile on the USB.  So if I were to just 
>> use:
>>
>> insmod luks
>> cryptomount -H (hd0,1)/header hd1,1
>>
>> along with the keyfile in the initramfs, then I would be asked for the 
>> password only once, by grub, correct?
> yes
>>
>> I'm not a guy who knows a lot about crypto, though I am aware that it can be 
>> quite delicate.  So I do have to wonder about the safety of having the key 
>> sitting around on disk (in the initramfs) while the OS is running.  Once 
>> decrypted by cryptomount, is there any way to pass that key on to the 
>> kernel?  Is this even feasible?
> I don't believe it's possible for the bootloader to pass an encryption
> key to the Linux kernel. I believe BSD lets you do that but not Linux.
> Doing so would be the sensible approach and I would do it if I could...
>
> You should chmod 600 your initrd in /boot and chown it to root if you
> haven't done so already. I think any encryption scheme falls back to the
> protection offered by the OS when it is unlocked. I guess your comfort
> level falls in line with your paranoia level. I'm personally not at the
> point where someone accessing a root-protected file on a running sytsem
> is a major concern. If someone's in my running system I'd have bigger
> things to worry about ;)

I think that the threat of someone gaining root access on your machine
and reading the initramfs from the filesystem should actually be the
least of your worries with your current scheme. As I understand it,
when the kernel pivots to the actual root filesystem and thus no
longer needs the initramfs that's loaded into RAM, it simply frees
that memory without first zeroing it. That means that a process,
running as any user, can just malloc ram and reads its uninitialized
contents in a loop until it comes upon something that looks like your
LUKS keyfile. Eventually, even if it takes multiple boots, it will
succeed. This is why it's so important that an official protocol be
developed between the kernel and bootloader, because then the kernel
knows to treat any memory containing credentials carefully and ensure
that it doesn't leak out to somewhere it shouldn't.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)