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

[Diagon]

> From: John Lane
> Date: Fri, 19 Dec 2014 11:21:31 +0000

>> On 19/12/14 10:09, Diagon wrote:

>>> Date: Fri, 19 Dec 2014 09:37:12 +0000 
>>> From: John Lane <address@hidden> 

[...] 

>>> I have some devices that are configured to boot from a USB drive that I 
>>> keep attached to my keys and, usually, in my pocket :) 
   
>>> These devices contain encrypted disks that have no boot sectors and 
>>> cannot boot themselves. The unlocked disks are LVM and contain a root 
>>> logical volume. This has a "/boot" directory containing the kernel and 
>>> initramfs images. 
  
>>> Booting Grub from the USB uses "cryptomount" to unlock the encrypted 
>>> disk and this allows Grub's LVM to activate the root volume. Grub then 
>>> uses the images in "/boot" on that volume to boot the system. There is 
>>> no need to maintain copies of the boot images on the USB drive. 
  
>>> 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.

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?

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?
 
[...]

>>> By having "/boot" on the root volume, it's easy to perform system 
>>> updates in-situ without having to worry about copying images onto the 
>>> USB stick (which may not be phyisically present when such an update is 
>>> performed). 

>> The USB does not hold the kernel/initramfs, but it does hold the /boot/grub 
>> partition, 
>> with core.img, modules and grub.cfg.  The OS does occasionally need to 
>> update that stuff, 
>> in which case the USB would need to be present, no?

> I don't see Grub as a dependency of the OS, so the two can be decoupled. 
> Unless I am missing
> something, there is no reason why an OS update would mandate a bootloader 
> update. 

[...]

> Whenever I update my OS, it installs new kernel and initramfs to /boot, 
> totally oblivious to how those files 
> get used.

It may be me missing something, but it has appeared to me that at times the 
Ubuntu updated has updated grub; though it's possible I could be mistaken.

/D