# [Solved] dmcrypt config options

## abduct

I've made a topic else where and I got a few answers that fixed most of my problems, but since then people have stopped replying so I am moving the topic to the security section to see if it gets more views or more knowledgeable people.

I've been working with /etc/conf.d/dmcrypt and I had a few questions about mounting file volumes, encrypted swap, and other things, which is all worked out now.

What I now want answered are the following questions:

How do you create a keyfile that dmcrypt can use? What settings should I use with gpg to create them? Are there any specific options to use this within the config?

When specifying a remote key such as that on a sd card or usb drive, does dmcrypt auto mount the device or do I need to write an init to mount it for me?

What does "remdev" do exactly?

Thanks for any answers you can provide me. This config file should really be more thoroughly documented either in the config itself or on the wiki.Last edited by abduct on Thu Jul 02, 2015 9:54 pm; edited 2 times in total

----------

## Keruskerfuerst

What kernel version are you using?

Are you using ext4?

----------

## abduct

 *Keruskerfuerst wrote:*   

> What kernel version are you using?
> 
> Are you using ext4?

 

3.18.9-hardened

Yes I am using ext4 for all file bearing partitions.

Let it be known this topic is more about the dmcrypt options than encrypting harddrives and data itself, since everything is already working in that department.

----------

## Keruskerfuerst

What sources have you read about dmcrypt options?

----------

## frostschutz

 *abduct wrote:*   

> What does "remdev" do exactly?

 

remdev stands for removable devices, it will ask you to insert the device, mount it, grab the key from it, umount it, so you can remove it afterwards.

As for gpg the default options are '-q -d' so any file that decrypts when calling it like gpg -q -d file.gpg should work.

----------

## abduct

 *frostschutz wrote:*   

>  *abduct wrote:*   What does "remdev" do exactly? 
> 
> remdev stands for removable devices, it will ask you to insert the device, mount it, grab the key from it, umount it, so you can remove it afterwards.
> 
> As for gpg the default options are '-q -d' so any file that decrypts when calling it like gpg -q -d file.gpg should work.

 

So if my sdcard was /dev/mmcblk0, if I specify

```
remdev=/dev/mmcblk0

key=/key/mykey.gpg

```

remdev will ask where I would like to mount the drive (/key in this instance) then it will take the key to unlock the drive, then automatically unmount /key? Or is specifying the key location not required as remdev will handle that? If I need to unlock multiple encrypted volumes each with a different key, is there an option to mount the sd card once take the keys that match, then unmount once everything is done? Being asked to mount, specify the key, and unmount, would seem like a pain when doing it 2-4 times in a row. If that is the case I will go back to my init scripts to handle the mounting and decryption/mounting of the volumes.

 *Keruskerfuerst wrote:*   

> What sources have you read about dmcrypt options?

 

https://wiki.gentoo.org/wiki/Dm-crypt

http://gentoo-en.vfose.ru/wiki/DM-Crypt#Encrypting_swap_and_.2Ftmp

https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption#Without_suspend-to-disk_support

I haven't found any sources specifically relating to the configuration of the dmcrypt config file which is why I've been asking around the forums.

----------

## frostschutz

You might have to read the fine source code (/etc/init.d/dmcrypt) or just try it and see...

----------

## abduct

 *frostschutz wrote:*   

> You might have to read the fine source code (/etc/init.d/dmcrypt) or just try it and see...

 

Didn't know the config file was used by an init script. Thought it was some other application that init can. I'll give it a read thanks!

----------

## tclover

It looks like you need to read this high level summary DM-Crypt LUKS on the wiki. It lack a few references but it should be enough to get you started on many aspects.

----------

## tclover

 *abduct wrote:*   

>  *frostschutz wrote:*   You might have to read the fine source code (/etc/init.d/dmcrypt) or just try it and see... 
> 
> Didn't know the config file was used by an init script. Thought it was some other application that init can. I'll give it a read thanks!

 

Yes, it's the configuration file used for OpenRC init script service! So, don't expect other init/service-system to parse it other than... booting with OpenRC! Else, having OpenRC start a few service with other init/service manager system can be done... If using SystemDebug... no idea how that tthing handle crypted root/devices in general.

----------

## abduct

 *tclover wrote:*   

>  *abduct wrote:*    *frostschutz wrote:*   You might have to read the fine source code (/etc/init.d/dmcrypt) or just try it and see... 
> 
> Didn't know the config file was used by an init script. Thought it was some other application that init can. I'll give it a read thanks! 
> 
> Yes, it's the configuration file used for OpenRC init script service! So, don't expect other init/service-system to parse it other than... booting with OpenRC! Else, having OpenRC start a few service with other init/service manager system can be done... If using SystemDebug... no idea how that tthing handle crypted root/devices in general.

 

I just gave it a read and answered most of my questions. I am going to play with it later tonight and then create some more descriptive comments or information about the config. If it is good enough someone could throw it on the wiki.

But as of now I found that 

`remdev` is for a removable device specified in the config file, and it will automatically create a temporary directory suffixed with the PID of the service being created, and then looks for the key which file name is given via the `key` option, rather than the full directory name.

An example config would be

```

target=crypt-home                         #name that the /dev/mapper uses

source=/path/to/device/or/file/volume     #path to the encrypted dev partition or encrypted file volume

key=home.gpg                              #name of the key to be looked for on the removable device, if remdev is not specified a full path is required to the key file

remdev=/dev/mmcblk1                       #device path to the removable media

         

                                          #remdev will be mounted at mntrem=${RC_SVCDIR)/dm-crypt-remdev.$$

                                          #and the key file it will be looking for would be located at ${mntrem}/home.gpg    

```

Although this is just what I've gathered from the init file. When I test it when I have time I will provide a more well written documentation and see if I can edit the wiki for the dm-crypt page to provide information on this config file which is missing from the docs.

----------

## abduct

I've decided to not use the dmcrypt init/config setup any longer. After reading through it a few more times and playing around with cryptsetup a bit more I have decided to write my own quick init script to handle everything I need. The reason for this change is that there is no option for dmcrypt to mount an luks encrypted removable media to obtain the keys to unlock the partitions on the system then unmount it.

I haven't added such a feature yet, but for anyone interested here is a quick script which loads an encrypted root/home and mounts them, and creates a new encrypted swap partition every boot:

```

#!/sbin/runscript

# Copyright 1999-2015 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

depend() {

        true

}

start() {

        ebegin "Starting encrypted file systems"

            einfo "Unlocking file systems"

        cryptsetup luksOpen /crypt/home.dm crypt-home

        cryptsetup luksOpen /crypt/root.dm crypt-root

        cryptsetup -c aes-xts-plain -h whirlpool -d /dev/urandom create crypt-swap /dev/disk/by-id/ata-ST500LT012-9WS142_S0V24AMG-part2

        einfo "Mounting file systems"

        mount /dev/mapper/crypt-home /home

            mount /dev/mapper/crypt-root /root

        mkswap /dev/mapper/crypt-swap

        swapon /dev/mapper/crypt-swap

        eend $?

}

stop() {

        ebegin "Stopping encrypted file systems"

            einfo "Unmounting file systems"

        umount /home

        umount /root

        swapoff /dev/mapper/crypt-swap

        eninfo "Locking file systems"

        cryptsetup luksClose crypt-home

        cryptsetup luksClose crypt-root

        cryptsetup remove crypt-swap

        eend $?

}

restart() {

        stop

        start

}

```

It is recommended to add some error handling or other checks (using isLuks maybe) to prevent the swap creation from obliterating a encrypted data partition. Another tip is to use /dev/disk/by-id/ rather than /dev/sdaX notation since I've read that the machine can swap the partitions around or rename them when new drives or media is attached when booting or something. It would be no fun to know that your swap partition named sda2 was moved to sdb2 and your nice new music collection now located at sda2 was destroyed. 

As of now though the topic is solved as I figured out what the options were for, and I decided to no longer use the premade script.

----------

## Keruskerfuerst

Sourcecode here:

http://lxr.free-electrons.com/source/drivers/md/dm-crypt.c

----------

## tclover

 *abduct wrote:*   

> [...] The reason for this change is that there is no option for dmcrypt to mount an luks encrypted removable media to obtain the keys to unlock the partitions on the system then unmount it.[...]

 

Looks like you you might be interested in in GnuPG... if you have that around. Just generate a good passphrase with `openssl rand -base64 48' and then crypt the string with GnuPG and a good passphrase and get that secure inprovement by feeding a good, long, and randomish passphrase instead of cascading LUKS devices. This is what many use for that purpose instead of cascading devices. You could even improve things by detaching the header from the cyphertext and put it in the same device that have the key-file. A last alternative is to use a tiny (dm-crypt/LUKS) crypted file with random data slightly bigger than 2MiB to get what you want... but there is no support for such a setup in the official init script. --Last(?) one, an ARCH Linux variant, is to embed the key-file somewhere (in disk) with dd for a supposedly improved security... --I don't find it that interesting. Follow my sig./mkinitramfs-ll for an overview of a few options. I'd rather use the official script with GnuPG... because that thing should be rock solid and scalable for possibly adding new devices. Well then, I guess hardcoding your simple usage in a script is fine as well.

Good luck!

----------

