[systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device

[Dimitri John Ledkov]

On 23 April 2015 at 13:08, Lennart Poettering <lennart at poettering.net> wrote:
> On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
>
>> > > > What does this actually do? Is the specified key file read from the
>> > > > specified device?
>> > >
>> > > It reads keyfile from filesystem on device identifed by keyfile_device.
>> > >
>> > > >                  The order of keyfile:device sounds weird, no?
>> > > > Shouldn't it be the other way round?
>> > > >
>> > >
>> > > keyfile is mandatory, keyfile_device is optional and can be omitted. I
>> > > believe dracut looked at all existing devices then. This order makes
>> > > it easier to omit optional parameter(s).
>> >
>> > Well, whether it is [device:]file or file[:device] is hardly any
>> > difference for the parser...
>>
>> Does it really matter?
>
> Well, we might as well implement this in the most obvious way if it is
> not a completely standard feature yet. To me it appears that only one
> initrd supported it, and it lost it a while back without too much
> complaining...
>
> But anyway, I don't mind too much. The
>

debian's initramfs-tools, but not ubuntu's, support keyfile on
usb-disk for unlocking luks volumes.

the exact name of the option and semantics to specify it to
initramfs-tools is different from dracut's (but that's typical) but
said equivalent feature does exist in the major other initramfs
implementation.

>> > > > Is this specific to Dracut so far? Is this widely used, and something
>> > > > that we really want.
>> > >
>> > > I can say about dracut only but yes, it is used and it is serious
>> > > regression when it is used comparing with pre-systemd version.
>> >
>> > Can you point me to documentation about the previous features in this
>> > regard? Which initrd implementations are you referring to?
>>
>> Sure, in dracut manual page:
>>
>>   crypto LUKS - key on removable device support
>>        rd.luks.key=<keypath>:<keydev>:<luksdev>
>>            keypath is a path to key file to look for. It’s REQUIRED. When
>>            keypath ends with .gpg it’s considered to be key encrypted
>>            symmetrically with GPG. You will be prompted for password on boot.
>>            GPG support comes with crypt-gpg module which needs to be added
>>            explicitly.
>
> To make this clear: the gpg support is crazy. I don't want to see that
> in systemd at all.
>
> Also, so far we don't allow <luksdev> to be specified for any of the
> other options, such as luks.options or so. I am not convinced we
> should support that here.
>
> I'd be willing to merge a patch that supports basic
> rd.luks.key=<keypath>:<keydev>, even though I think it's usecase is
> more security theater than really useful.
>
> But please put the temporary mount into /run, keep it minimal, define
> a clear trigger to unmount it, no gpg, no <luksdev> support.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.