| View previous topic :: View next topic |
| Author |
Message |
nms
n00b
Joined: 16 Jul 2005
Posts: 43
Location: Umeå, Sweden
|
 Posted: Sun Aug 27, 2006 4:34 pm Post subject: /etc/conf.d/cryptfs vs cipher key on USB stick |
 |
|
I wasn't quite sure which section to post this into, so I'm relying on the moderators to toss this thread in the general direction of a better destination should this be an awful section to post in.
The situation:
Shiny, new box with 160GB SATA disk partitioned as follows:
| Code: | /dev/sda1 1 12 96358+ 83 Linux
/dev/sda2 13 136 996030 83 Linux
/dev/sda3 137 385 2000092+ 83 Linux
/dev/sda4 386 19457 153195840 5 Extended
/dev/sda5 386 1007 4996183+ 83 Linux
/dev/sda6 1008 1629 4996183+ 83 Linux
/dev/sda7 1630 4119 20000893+ 83 Linux
/dev/sda8 4120 6609 20000893+ 83 Linux
/dev/sda9 6610 19457 103201528+ 83 Linux |
with /etc/fstab looking like this:
| Code: | /dev/sda1 /boot ext3 noauto,noatime 1 2
/dev/sda3 / ext3 noatime 0 1
/dev/sda5 /usr ext3 noatime 0 0
/dev/sda6 /home ext3 noatime 0 0
/dev/sda7 /var ext3 noatime 0 0
/dev/sda8 /data ext3 noatime 0 0
/dev/mapper/crypt-data /data/crypt ext3 noatime 0 0
/dev/mapper/crypt-swap none swap sw 0 0
/dev/usbcf /mnt/usb vfat nodev,nosuid,noexec 0 0 |
I'm using /etc/conf.d/cryptfs to manage /dev/mapper/crypt-{data,swap}, the relevant parts of that file being
| Code: | swap=crypt-swap
source='/dev/sda2'
mount=crypt-data
source='/dev/sda9'
type=luks
options='-d /mnt/usb/index.dat' |
The problem:
Let's ignore the crypt-swap bit (which works just as it should) and focus on the problem at hand, namely crypt-data, which uses a cipher key file stored on a USB memory stick. The idea is that if the memory stick is plugged into one of the computer's USB connectors it should be mounted at boot, and then Gentoo's built-in cryptsetup magic can use the key file to decipher /dev/sda9 and map it to /dev/mapper/crypt-data before the mapped pseudo-device is mounted to /data/crypt. Should the USB memory stick not be connected or the key file not be found when looked for, the whole process will of course fail, which is exactly what I want as long as it doesn't lock up the rest of the boot process.
The issue I've been trying without success to sort out today is that the configuration in /etc/conf.d/cryptfs is taken care of before /etc/init.d/localmount is executed, with the obvious result that the USB memory stick (the one with the cipher key file) has not yet been mounted when /dev/sda9 is to be mapped to its deciphered pseudo-device.
The actual question:
Is there any way to configure the cryptfs stuff to be taken care of after localmount, with localmount obviously ignoring the cryptfs devices? |
|
| Back to top |
|
 |
nms
n00b
Joined: 16 Jul 2005
Posts: 43
Location: Umeå, Sweden
|
| Posted: Sun Aug 27, 2006 9:24 pm Post subject: |
|
|
So, instead of releasing my unimaginable powers of editing(tm) on the Gentoo scripts and configuration files to resolve this issue in lack of direct support for my specific needs I created a little script with its own configuration file and stored them in the /usr/local/ tree, and then added the script to /etc/conf.d/local.st{art,op}. Works like a charm.
If anyone else needs something like what I described in my previous post, let me know and I'll hook you up. |
|
| Back to top |
|
|
Reikinio
Apprentice
Joined: 14 Aug 2005
Posts: 203
Location: Uruguay
|
| Posted: Mon Aug 28, 2006 1:15 pm Post subject: |
|
|
After seeing your post, I did a rewrite of dm-crypt-start.sh just for you  , it supports some of the things you mentioned, you can use keyfiles or gpg encrypted keys from usb-sticks with it, if you want to use/see it, get it here(bugreport).
No warranties though, consider it a testing release and do not use it on any important system. |
|
| Back to top |
|
|
nms
n00b
Joined: 16 Jul 2005
Posts: 43
Location: Umeå, Sweden
|
| Posted: Mon Aug 28, 2006 4:36 pm Post subject: |
|
|
Thank you for taking my problem serious, although I didn't expect anyone to go ahead and edit the Gentoo scripts just for me. 
After reading your post in bugzilla I'm seriously considering ditching my own solution in favour of yours. You seem to have done exactly what I wanted to do but was too lazy to edit the Gentoo scripts to accomplish.
I will download your attached files and take a look at them, and most likely implement them in my two Gentoo installations when I'm done installing all the other stuff that's on my list at the moment. |
|
| Back to top |
|
|
bits'n'booze
n00b
Joined: 19 May 2004
Posts: 25
Location: Germany
|
| Posted: Wed Aug 30, 2006 10:23 am Post subject: |
|
|
EDIT: Another question came up 10minutes after the original posting.
| Quote: | After seeing your post, I did a rewrite of dm-crypt-start.sh just for you , it supports some of the things you mentioned, you can use keyfiles or gpg encrypted keys from usb-sticks with it, if you want to use/see it, get it here(bugreport).
No warranties though, consider it a testing release and do not use it on any important system. |
Reikinio: Are you aware if this is going to become the standard in sys-fs/cryptsetup-luks ? Are you in contact to the package maintainer already (or is this you as well?)? Does the maintainer work on implementing this maybe already? I ask you, because you also wrote the gentoo-wiki.com howto, so you seem to be the right person to ask...
I did not try your solution yet, but likely I will during the next couple of days. Just asking because i _must_not_ risk screwing up my system, at least not till the weekend  . For now i am fine (and running smoothly) with entering the keys manually.
IMHO, the possiblity to use USB-sticks that contain one or more keys during boot is definitely needed. For security reasons as well as for convinience - I have 6 encrypted partitions in my system, and entering 6 keys during boot is somewhat PITA to me...
Is there / will there be a way of using both methods during boot? E.g. to look for keyfiles (slot-0) on a USB-Stick first, but if that fails (=no stick present) I could still enter a passphrase (slot-1)?
Anyway: Great work, especially the howto in the wiki. Thank you very much.
_________________
---
Adopt an unanswered post today! |
|
| Back to top |
|
|
nms
n00b
Joined: 16 Jul 2005
Posts: 43
Location: Umeå, Sweden
|
| Posted: Wed Aug 30, 2006 7:34 pm Post subject: |
|
|
Personally I'm implementing this on a headless server, so having the system ask me for a passphrase on boot and wait until the end of days for me to enter one instead of just bailing and skipping that particular filesystem would be a serious PITA for me.
What I'm saying is that for my personal needs (and for many others wanting to use this on a headless system), the encrypted filesystem should simply be left inactive if the keyfile is not found on the specified USB stick. |
|
| Back to top |
|
|
lkraav
Tux's lil' helper
Joined: 13 Oct 2004
Posts: 129
Location: Estonia
|
| Posted: Fri Sep 01, 2006 11:36 am Post subject: |
|
|
hi reikinio
is it possible to have a an option in cryptfs that would stop booting until the valid key can be loaded from a removable device.
actually i am looking for the same behavior as your init in the dm-crypt luks HOWTO, but since i am not encrypting root filesystem on this box,
i could use that behavior with dm-crypt-start.sh. if there is no usb device, then wait until its inserted and try to load. if no valid key found on usb stick, tell the user to try another one.
since i have many of daemon data files and also /home directories in the crypted partition, there would essentially be no point in booting further before being able to decrypt.
edit: switching to gpg passphrase protected keys sort of solves this, but if the designated media is not there, i'd still like the script to wait around until its inserted |
|
| Back to top |
|
|
Reikinio
Apprentice
Joined: 14 Aug 2005
Posts: 203
Location: Uruguay
|
| Posted: Thu Sep 07, 2006 7:14 pm Post subject: |
|
|
Hi,
First of all, sorry for the long delay
For the last 8 days I've been working on a adding dm-crypt support to Alon Bar-Lev's init(see document), the idea is having the same init supporting both encryption methods(loop-AES and dm-crypt).
The good news is that it supports a lot of things:
* custom made cryptfs implementation(all cryptfs stuff will be done in initramfs)
* Suspend2
* keys on removable media
* PKCS#11
* booting both encrypted and unencrypted root partitions
* ...
It's pretty much finished, it's not realeased yet, I'm currently looking for people interested in testing it. 
If you want to test it out, contact me via email, I'll send you a copy.
| bits'n'booze wrote: |
Reikinio: Are you aware if this is going to become the standard in sys-fs/cryptsetup-luks ?
|
It depends on the Gentoo developer(strerror), I doubt it will, but he might take some ideas from it(or not), it's entirely his decision, I don't know since there is no reply to the bug report yet.
The major drawback to it is that it access the removable media once for each key(the new init does not do this).
| bits'n'booze wrote: |
Are you in contact to the package maintainer already (or is this you as well?)? Does the maintainer work on implementing this maybe already?
|
Nope.
No idea.
| bits'n'booze wrote: |
I ask you, because you also wrote the gentoo-wiki.com howto, so you seem to be the right person to ask...
|
I don´t know, I don't claim to be an expert or something(I am not), I'm just an end user like you.
| bits'n'booze wrote: |
IMHO, the possiblity to use USB-sticks that contain one or more keys during boot is definitely needed. For security reasons as well as for convinience - I have 6 encrypted partitions in my system, and entering 6 keys during boot is somewhat PITA to me...
|
I've to enter 2 passphrases when booting my laptop and it annoys me as well.
So, I came up with a simple solution for the new init, a one pass solution to decrypt several partitions.
It works like this: encryption keys are inside a gpg encrypted file on removable media(usb-stick), one key per line.
Then at boot init decrypts the file and it fetchs the correct key(line) for each partition, you control it via a custom made cryptfs file(like Gentoo's, but different.)
It's simple really, nothing complex or anything, just one file with all the keys and a 'head -n <N> | tail -n 1' combination to fetch the correct line, It's better explained in the new init's cryptfs file.
| bits'n'booze wrote: |
Is there / will there be a way of using both methods during boot? E.g. to look for keyfiles (slot-0) on a USB-Stick first, but if that fails (=no stick present) I could still enter a passphrase (slot-1)?
|
The new init supports asking for passphrase if keyfile fails(you have to enable this behavior),
What you said can also be added, like waiting for x seconds for remoable device to be available and defaulting to asking for passphrases if this happen.
| bits'n'booze wrote: |
Anyway: Great work, especially the howto in the wiki. Thank you very much. |
Thanks. 
| nms wrote: |
Personally I'm implementing this on a headless server, so having the system ask me for a passphrase on boot and wait until the end of days for me to enter one instead of just bailing and skipping that particular filesystem would be a serious PITA for me.
What I'm saying is that for my personal needs (and for many others wanting to use this on a headless system), the encrypted filesystem should simply be left inactive if the keyfile is not found on the specified USB stick. |
I think that the problem is telling Gentoo's init scripts to ignore a set of fstab entries(the failed to decrypt partitions).
A dirty way that doesn't require editing init scripts is commenting and uncommenting the proper line in fstab depending on whether or not the partition was decrypted succesfully, but I don't like this "solution". I think you're better off with your local script that handles it(btw: you should post your script here or in the Docs && Tips section, someone might find it useful)
| lkraav wrote: |
hi reikinio
is it possible to have a an option in cryptfs that would stop booting until the valid key can be loaded from a removable device.
actually i am looking for the same behavior as your init in the dm-crypt luks HOWTO, but since i am not encrypting root filesystem on this box,
i could use that behavior with dm-crypt-start.sh. if there is no usb device, then wait until its inserted and try to load. if no valid key found on usb stick, tell the user to try another one.
since i have many of daemon data files and also /home directories in the crypted partition, there would essentially be no point in booting further before being able to decrypt.
edit: switching to gpg passphrase protected keys sort of solves this, but if the designated media is not there, i'd still like the script to wait around until its inserted
|
Done in the new init cryptfs implementation, you can also use the new init to boot into unencrypted root.
Note: If you don't like the idea of creating initramfs archives yourself, you should know that it's possible to use the new init and let genkernel handle initramfs creation, instructions for it are in Alon's site.
Take care |
|
| Back to top |
|
|
nms
n00b
Joined: 16 Jul 2005
Posts: 43
Location: Umeå, Sweden
|
| Posted: Fri Sep 15, 2006 10:22 am Post subject: |
|
|
Sorry for taking my time before logging back in here and checking for updates. I've had my hands full with RL stuff lately, so I haven't bothered to check back in on the forums in the event that it would give me more things to take care of. Fortunately, this wasn't the case.
Here's my own Bash script hack to take care of the deciphering and mounting:
| Code: | #!/bin/sh
cm_conf=/usr/local/etc/cryptmount.conf
test "${2}" || exit 0
if [ "${1}" = "start" ]; then
cm_usb=$(grep "usbdev=" ${cm_conf} | cut -d : -f 1 | cut -d = -f 2)
test "$(stat -L -c %F ${cm_usb} 2>/dev/null)" = "block special file" || exit 0
cm_mnt=$(grep ${cm_usb} /etc/fstab | awk '{ print $2 }')
test -d "${cm_mnt}" || exit 0
test -d "$(grep '^/dev/mapper/'${2} /etc/fstab | awk '{ print $2 }')" || exit 0
cm_tmp=$(grep "mount=${2}" ${cm_conf})
cm_dev=$(echo ${cm_tmp} | sed -e s/"^.* source=\([a-z0-9_\.\/-]*\).*$"/"\1"/)
cm_key=$(echo ${cm_tmp} | sed -e s/"^.* keyfile=\([a-z0-9_\.\/-]*\).*$"/"\1"/)
/bin/mount ${cm_usb}
/bin/cryptsetup -d ${cm_mnt}/${cm_key} luksOpen ${cm_dev} ${2} &>/dev/null
/bin/umount ${cm_usb}
/bin/mount /dev/mapper/${2}
fi
if [ "${1}" = "stop" ]; then
/bin/umount /dev/mapper/${2}
/bin/cryptsetup luksClose ${2}
fi |
For those of you who can't decode my regex magic, here's my cryptmount.conf:
| Code: | usbdev=/dev/usbcf
mount=crypt-data source=/dev/sda9 keyfile=index.dat |
The related lines from /etc/fstab look like this:
| Code: |
/dev/mapper/crypt-data /data/crypt ext3 noatime,noauto 0 0
/dev/usbcf /mnt/usb vfat nodev,nosuid,noexec,noauto 0 0 |
Note the 'noauto' option on /dev/mapper/crypt-data to prevent the system from trying to mount it itself. Also note that the USB memory stick device (specified with usbdev= in cryptmount.conf above) needs to have a line in /etc/fstab for my script to find the mount point.
To get the filesystem up and running at boot I use /etc/init.d/local, which reads /etc/conf.d/local.start, to which I have added this line:
| Code: | | /usr/local/sbin/cryptmount start crypt-data |
Since I like stuff to run properly, I also added this line to /etc/conf.d/local.stop:
| Code: | | /usr/local/sbin/cryptmount stop crypt-data |
Neat, huh?
This script was written for luks since that's what I'm using. It's a quick hack for my own system and not intended for official release, and as such will not be modified by myself for other people's wants and/or needs.
The license is quite simple: You are free to use the script in whatever way makes your clock tick, and by using it you acknowledge that I have no responsibility what so ever for any events that may or may not occur from the use of the script. Steal whatever parts of the script that you like (or the whole script if you're lazy), but if you use a line or more from my code in your own stuff and end up releasing your stuff to anyone else, please put my name in there somewhere and make me famous.
Oh, and if you find obvious bugs somewhere in this, please let me know. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
