On Thu, 29 Aug 2013 21:20:14 +0100 TJ <grub-de...@iam.tj> wrote: > that'd be silly so I'm now moving to whole-disc encryption with the > boot-loader, kernel, and initrd on a key-fob USB. > > I'd still like GRUB to be able to read a key-file rather than a typed > pass-phrase, and have the key-file hidden on a (second) small (1GB) > randomised-data USB flash device (no file-system) so even the > operator can't be sure where to find the bytes that unlock it.
Again. If your initrd and kernel are unencrypted on the USB, then you don't need keyfile support or any encryption support in grub. Grub can just load your linux environment and then you can have linux do all the heavy lifting. > If we can figure it out we'd like to be able to configure/unlock > different LVM volumes based on which LUKS slot is used to unlock, > too, and log the LUKS attempts from GRUB. This really doesn't make sense. LVM volumes aren't "unlocked", LUKS volumes sure. And restricting access based on what key was used doesn't make much sense either. LUKS key slots are for getting the single master key. So regardless of which key slot used, you get back the master key that can decrypt the _whole_ luks container, yes all the LVs. So in this hypothetical system, for any key slot used root will be able to access all the LVs. Why exactly are you wanting to activate an LV based on LUKS keyslot? Is it because you want to prevent other users from accessing the other LVs? or is it merely to provide a mechanism for booting different OSes (with no security implications)? And I see no reason why you're needlessly trying to use grub, unless your initrd or kernel are encrypted on the USB. Linux would be a much more capable environment to work in. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
