[pkg-cryptsetup-devel] Bug#786578: Bug#786578: cryptsetup: crypt asks passphrase instead of using keyfile

Jonas Meurer jonas at freesources.org
Thu Dec 10 08:38:03 UTC 2015


Hi Guilhem,

Am 10.12.2015 um 01:01 schrieb Guilhem Moulin:
> On Wed, 09 Dec 2015 at 23:28:51 +0100, Jonas Meurer wrote:
>> Am 09.12.2015 um 19:58 schrieb Guilhem Moulin:
>>> I forgot an important piece of information: UMASK should be changed to
>>> 0077 to ensure that regular users can't access the keys.
>>
>> Sounds reasonable. I added it the the SVN repository for now. But am I
>> correct that setting the UMASK in initramfs.conf will have an impact on
>> all files that are added to the initramfs? This might lead to unwanted
>> side effects.
> 
> No, you're not :-P   UMASK is documented in initramfs.conf(5) as
> follows:
> 
>     “UMASK Set the umask value of the generated initramfs file.  Useful to
>      not disclose eventual keys.”
> 
> Indeed the generated initrd.img is created with permission 0644 minus
> $UMASK (which defaults to the process' umask(2)), while files are being
> being copied ignoring the $UMASK value.

Ah, I see. Thanks a lot for explaining and sorry for my ignorance.

>     ~$ sudo lsinitramfs -l /initrd.img | grep scripts/local-top/cryptroot
>     -rwxr-xr-x   1 root     root         9608 Dec  9 05:08 scripts/local-top/cryptroot
>     ~$ sudo ls -l /boot/initrd.img-4.2.0-1-amd64
>     -rw------- 1 root root 4128472 Dec  9 21:40 /boot/initrd.img-4.2.0-1-amd64
>  
>> Why not set the key file permissions directly while copying it to the
>> initramfs in cryptroot hook?
> 
> That would defeat the purpose of keep regular users at bay from the
> private key material.  As long as I have read access to the initrd.img I
> can decompress it (possibly on another machine) and read the content of
> any file it contains, regardless of their permission.  Pretty much like
> a tarball.

Makes sense. So we'll leave it as it is now and I was simply wrong :)

Cheers
 jonas



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20151210/8545a4de/attachment.sig>


More information about the pkg-cryptsetup-devel mailing list