[pkg-cryptsetup-devel] Bug#839994: Bug#839994: Newest version prevent boot of full encrypted disk

[Guilhem Moulin]

On Fri, 07 Oct 2016 at 13:56:27 +0100, Klaus Ethgen wrote:
> Am Fr den  7. Okt 2016 um 13:04 schrieb Guilhem Moulin:
>> I see.  Indeed, we've unfortunately been too fast at releasing a fix for
>> #786578.  That is, we documented setting KEYFILE_PATTERN
>> /etc/initramfs-tools/initramfs.conf (or alternatively, under
>> /etc/initramfs-tools/conf.d) while the initramfs-tools maintainers later
>> (#807527) objected to using /etc/initramfs-tools for hook configuration:
>> 
>>    ???If a hook script requires configuration beyond the exported
>>    variables listed below, it should read a private configuration file
>>    that is separate from the /etc/initramfs-tools directory.  It must
>>    not read initramfs-tools configuration files directly.??? ???
>>    initramfs-tools(8)
>> 
>> Can you confirm your system boots as expected once you delete
>> /etc/initramfs-tools/conf.d/diskkey and use
>> /etc/cryptsetup-initramfs/conf-hook instead?
> 
> Partly. It will boot but the rights of the resulting initrd are 0644, so
> world-readable with credentials in it.

UMASK *is* a mkinitramfs(8) option, so setting UMASK should stay in
/etc/initramfs-tools.  Modifying UMASK from the hook script doesn't have
any effect since it's exected in a subshell.  On the other hand its
value is accessible read only, and the hook script prints a warning if
it's too permissive.

As of 2:1.7.2-1 you'll find the following under
/usr/share/doc/cryptsetup/README.initramfs:

    12. Storing keyfiles directly in the initrd
    -------------------------------------------
    Normally devices using a keyfile are ignored (with a loud warning), and
    the key file itself is not included in the initrd, because the initramfs
    image typically lives on an unencrypted /boot partition. However in
    some cases it is desirable to include the key file in the initrd; for
    instance recent versions of GRUB support booting from encrypted block
    devices, allowing an encrypted /boot partition.

    Among the key files listed in the crypttab(5), those matching the value
    of the environment variable KEYFILE_PATTERN (interpreted as a shell
    pattern) will be included in the initramfs image. For instance if
    /etc/crypttab lists two key files /etc/keys/{root,swap}.key, you can add
    the following to /etc/cryptsetup-initramfs/conf-hook to add them to the
    initrd.

      KEYFILE_PATTERN="/etc/keys/*.key"

    Furthermore if the initramfs image is to include private key material,
    you'll want to create it with a restrictive umask in order to keep
    non-privileged users at bay.  This can be achived by adding the
    following to /etc/initramfs-tools/initramfs.conf.

      UMASK=0077
 
>> I'll push a proper fix
>> later today, to make the latter config file take precedence over
>> mkinitramfs(8) settings; but *not override them* as it's incorrectly
>> done now.
> 
> Well, just keep 'em commented out I would says that will fix it?

Yup nothing fancy as the hook isn't executed with -u anyway.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20161007/39ab7efa/attachment.sig>