here is an ebuild for dm-crypt (attaching). dm-crypt is a replacement for cryptoloop that is built on a saner architecture, and is more secure. ebuild contains first draft of dm-crypt init script which loads a config similar to crypto-loop, sample conf, etc. i used -mm kernel as a depend, there are some other kernels that support dm-crypt so I'll leave it to the full-timers to figure out how best to resolve this dep, or leave it... Used Cristophe Saout's cryptsetup as template, although note that I REQUIRE hashing (he doesn't) as plaintext is vulnerable to optimized dictionary attack, and the whole idea of moving to dm-crypt is to be MORE secure, and give false sense of security. my first ebuild pls be gentle ;) TODO: I can't get this thing to load BEFORE localmount no matter what I do. In fact I can't get crypto-loop to either. What's up with this? help appreciated. find solution to the must-use-encrypted-swaps issue so that we can ensure no keys are leaked to swap (need to mlock the pages, somehow...)
Created attachment 26492 [details] dm-crypt 1.0 ebuild here's the tarball, sorry for formatting (above). echk.
extracts to sys-apps/dm-crypt
submitted a patch to device-mapper-1.00.07 ebuild that secures dmsetup's pages against swapout - I'll modify the init script to do a direct pipe from hashalot to dmsetup. after that people will be able to encrypt block devices leaving swap space unencrypted, and not have to worry about keys leaking to unencrypted disk. checkout http://bugs.gentoo.org/show_bug.cgi?id=43162 for details
patch to device-mapper on hold.
submitted bug for 'no hashalot-0.2 ebuild' (hashalot 0.2 supports seeds) changed init script to correct some errors in the genkey function that caused things not to be einfo and ewarn'd correctly. changed ebuild to require hashalot-0.2 ebuild (see http://bugs.gentoo.org/show_bug.cgi?id=43257). This version supports seeds. changed init script to include support for seeds. I make it pickup the 'seed=myseed' option out of /etc/conf.d/dm-crypt and look for /etc/seeds/myseed.seed, passing that along to hashalot if present. pls let me know if this is not appropriate, etc. attachments follow...
Created attachment 26567 [details] changes described above. extracts to sys-apps/dm-crypt
Created attachment 26568 [details] oops, s/seed/salt oops, used 'salt=' in init script and 'seed=' everywhere else. fixed up.
Created attachment 26578 [details] fixes to previous Fixed the .rc to clear out old salt settings. Killed the "other=" option in the .conf file, the settings "skipped" and "offset" can be specified just as with the other settings in the .conf. Fixes to broken getkey function. Cleaned up the .conf and added more doc to it.
I've started writing a native cryptsetup tool in C. Should be fully functional though far from feature-complete. It's better than the temporary shell script hack... http://www.saout.de/misc/dm-crypt/cryptsetup-0.1.tar.bz2 It uses libgcrypt for the hashes (and for other ciphers in the future for on-disk metadata/keys).
Created attachment 26953 [details, diff] Patch for handling swap space better Here's my little contribution. This patch will add a "type" field, that can be either "disk" or "swap". swap devices will be created by reading random data from /dev/urandom (no password) and mkswap will be run on the resulting device after it's created.
Created attachment 27067 [details] 0.1 ebuild
new ebuild (above) LOTS of changes. Broke off dm-crypt from new cryptsetup ebuild see http://bugs.gentoo.org/show_bug.cgi?id=44079 called new build 0.1 to be consistent with cryptsetup. No longer uses cryptsetup.sh but cryptsetup from above ebuild (Thanks Cristophe!) now cryptsetup has all the deps, this is just an empty ebuild to install the init scripts and /etc files and so forth, and will probably get merged down into baselayout or so. merged Vadim Trochinsky's changes (Thanks Vadim!), but changed it around so that only "type=swap" needed, not "type=disk" to keep it clean. so now swaps are quick and automatic now supports use of "keyfile=" to load key from file and pass to cryptsetup. removed all of the salt stuff from the rc and conf until cryptsetup has these. no point in rushing it.
In the future, could you please attach ebuilds in text format? This is very helpful to us.
this is something i've had on my planned subproject list for a while (http://hardened.gentoo.org) and this is an even better implementation than the previously available ones. I'd love to see all this stuff available and am willing to pull it under hardened. the only thing that is really needed aside from the ebuilds, inits, etc is a very good and clear howto in gentoo xml format. Since i've just begun experimenting with it how do you guys feel about trying to come up with something?
more changes: gracefully skips mounted devices/swaps (thanks again to Vadim) added 'usekey=' variable: allows recycling a key that has already been used, so if you have, say, 3 block devices and want to use the same key for the other 2 you used on the first one, you can. Shouldn't be used without encrypted swap, however. Will up shortly after I hear back from Brandon.
Created attachment 27268 [details] newest version of init script No word about how exactly i'm supposed to submit this beast. In the meantime checkout the latest init script. This one implements the usekey= variable. If you have 4 devices in your conf.d/dm-crypt file, and you specify 'usekey=1' for the last three, the script will only prompt you once: the first time you enter the password. the other 3 devices will reuse this pass. This should not be used with unencrypted swap. This should be used with a *strong* *hashed* passphrase only. In the future the use of salts should be used to increase protection if using 'usekey'.
idea: how about a small patch to add something like what I did for swap, except for normal filesystems? For example, I think that having /tmp done this way could be good. /tmp, like swap will hold data that's been used in calculations, and might have something sensitive. It could also help improve security. If you don't want to have traces of something (cache, temporary results, whatever), put it on encrypted /tmp, and it's all gone with just resetting the computer. Sounds good?
Bug ping. Any progress on this ebuild, or is it stalled?
Attaching a cleaner implementation (imho) of an init script for dm-crypt. To make use of it: $ echo checkroot hostname modules checkfs cryptomount localmount > \ /etc/runlevels/boot/.critical $ rc-update add cryptomount boot Setup a /etc/conf.d/crypomount (sample attached) Patch halt.sh (patch attached) The cryptomount either needs to be rolled into localmount or it needs to be added to baselayout but have the "critical" default changed so it can run when its needed.
Created attachment 36320 [details] init script
Created attachment 36321 [details] sample config file
Created attachment 36322 [details, diff] halt.sh patch
Created attachment 36323 [details] actual conf file ;P
my feeling regarding the patches from #20-#22 is that it would be better to use /dev/urandom instead of /dev/random. the thing is that /dev/random can easily be depleted and there is little entropy upon the restart of a system. my 2c
*nod* my bad. shan't submit a new version, but that should be changed
bootmisc should probably be changed to always chmod 1777 /tmp in case its been mounted from a freshly created filesystem.
hey this is great stuff :) I have made the following changes for my system (I like ext3fs ...) in the init script instead of if ! ${makefs} /dev/mapper/${target} > /dev/null please consider placing if ! eval "${makefs} /dev/mapper/${target}" &>/dev/null this is needed for 2 reasons: 1. in my etc/conf.d/cryptomount I have mount=crypt-tmp options="-d /dev/urandom" source=/dev/hda10 makefs='echo y| /sbin/mkfs.ext3' so that the makefs must be evaluated. 2. the '&>/dev/null' is there because the mkfs.ext3 sends commercials to my stderr
Well, the code should be moved from the seperate init script into checkfs where all the lvm/raid and evms stuff is set up. Currently I'm experiencing an issue when a dm-crypt filesystem is mounted on /tmp. On shutdown halt.sh fails to unmount it, because of processes still having open files on it. fuser -m /tmp only shows me one process having open files, but there are definitely more processes. Need to look deeper into it.
sven: I had the same problem with unmounting /tmp and the culprits were gpg-agent and ssh-agent. maybe this can help ...
petre: Thanks, I already identified ssh-agent, but there seem to be more processes that don't get listed by running fuser. The open files are listed by running lsof.
discussed on irc with kaiowas. best to use the -q flag to mk.ext3fs rather than snaffling stderr. We want to know if something goes wrong.
please see: http://bugs.gentoo.org/show_bug.cgi?id=58769 my hunch is that the /tmp issue is not directly related to md-crypt, given the fact that fuser misses some processes even on a non-md-crypt type /tmp.
I'm going to change this to a patch to baselayout as suggested by sven. I'll post when its done.
Created attachment 36463 [details, diff] Rolled init script + config file into baselayout
Created attachment 36464 [details, diff] Unbroken patch Didn't tidy up properly before diff'ing last time. sorry :)
What is wrong with a seperate script ? checkfs is already cluttered a lot - we try to do things more modular ...
The partitions must be ready after LVM partitions are setup but before any fsck are run. There is no way to do with other than patch checkfs. Likewise in halt.sh, these partitions must be removed after filesystems have been unmounted, but before LVM partitions are removed. If you would like things to be more modular you need to cut checkfs, halt.sh and localmount into pieces.
Then I will just have to come up with something more sufficient. We currently have lvm, lvm2, dm, raid, crypto-loop, dmcrypt, with I am sure more to follow.
what kind of timeframe do you see for this?
Next few days?
Patch to /sbin/rc so that lvm and dm-crypt mappings are recreated after the tmpfs is mounted to /dev. Needed if the / filesystem is mounted from a dm-crypt mapping inside an initrd.
Created attachment 37800 [details, diff] patch to /sbin/rc
Oh, I should mention that this information was kindly provided by Christophe, the author of dm-crypt. Thanks Christophe :)
Az, how is the refactoring coming? do you need any help from tigger or anyone to get it implemented? We are looking forward to being able to have fully encrypted systems without hacking up init scripts so this will help tremendously.
Just add this for now. I need to talk to Aron still, etc, but wont get to it soon enough for you I think. I will redo the filesystem stuff at some later stage - its not that critical anyhow (need to think about it to support some weirder / setups ...). Aron, you up to it (Adding dm-crypt patch to CVS)?
Comment on attachment 27067 [details] 0.1 ebuild I don't know what this garbage is, but it isn't plain text, so obsoleting the attachment
Tigger, do the following attachments have any relevance to baselayout? Patch for handling swap space better newest version of init script I have the other stuff in my local rc-scripts, pretty much ready for a baselayout release this afternoon. It will be a pmasked release for other reasons, but it works to my advantage because you'll be a network-scripts guinea pig in order to be able to get your dm-crypt stuff. ;-)
aron, only the last two attachments are part of my implementation. thanks for commiting :) I'll resolve this now.
Please don't resolve yet, I haven't released baselayout...
Aron, the dm-crypt integration is missing a file /etc/conf.d/cryptfs.
Created attachment 40036 [details, diff] apply on top of tigger's patch Tigger, considering our conversation on #-dev, want to try this version? It is completely untested at the moment, but I've proofread it pretty carefully. This version will accept conf.d files like your original one, or you can do files that look like lilo or grub configuration, where mount=... or swap=... starts a section. This version also fixes the other problems we talked about: setting cryptfs_status in a subshell and clearing of source. I'm not completely happy with it because of the code duplication between checkfs and localmount, but that can be solved later. I've already made sure that the duplicated sections are truly duplicated (dm-crypt-start) and not just almost duplicated.
Created attachment 40037 [details, diff] updated version which works with old conf.d/cryptfs
aron, it breaks. you've typo'd dm-execute as dmexecute twice, also it seems that the boot procedure doesn't like shopts -s extglob stuff. it complains about syntax errors. I had to add shopt -s extglob to /sbin/runscript.sh and even now each time I boot the dm-crypt stuff barfs, then I need to do /etc/init.d/checkfs restart and then /etc/init.d/localmount restart to get a working system. Can we drop the extglob stuff please?
Created attachment 40114 [details, diff] another updated patch Ok, try this one. Sorry the last one was a disappointment.
Sorry about that, Tigger. Try baselayout-1.11.1 and let me know how it goes. It also includes the default conf.d/cryptfs file now.
the problem with 1.11.1 is that it *enables* cryptfs by default that means if you just emerge 1.11.1 and reboot, you get a lot of ugly errors ... most users would have to go in and manually disable cryptfs (once they figure out wtf cryptfs is heh) ive updated cvs to fix this but havent made any sort of release
i also updated the check to make sure the binary exists
aron, I've tested the 11 release and it works very nicely for me wrt to dm-crypt stuff. The default config gave me an encrypted /tmp and swap without needing to change a thing :) The bad thing is, it will also give everyone else the same even if they don't ask for it :) But vapier's changes should fix that.
in baselayout-1.11.2 file a new bug if you have problems with it
*** Bug 78420 has been marked as a duplicate of this bug. ***
