This is a tutorial for experts and experienced slax builders on how to configure a user with an encrypted home directory, running the Slax 6.12 live distro from a USB stick. I was inspired by fanthom's excellent work:http://www.slax.org/forum.php?action=view&parentID=51502 Fanthom's design is better and more comprehensive, but mine easily saves private data. My solution simply decrypts a volume that could be a container for home directories. The slax distro itself is unmodified and readable (and creatable) exactly as normal Slax. The encrypted home directory container is unlocked and mounted by the root user before the crypto-user is able to log in. Everything in crypto-user's home directory is encrypted into a loop mounted dm-crypt LUKS container, and the container is closed and unmounted automatically at shutdown.
In a perfect world where someone else does the work outside my competency, I wish I could use PAM to pass crypto-user's kdm login credentials to cryptsetup. Anyway slackware doesn't support PAM and I'm not confident in my skills to do a tricky PAM configuration securely. So for now this solution requires root to run a command to mount the encrypted volume.
In theory my solution could well leak clear data in forseeable usage scenarios, but in practice my applications seem to work well with my approach, so while I recommend your personal understanding, review, and audit of this solution, it seems to work really well and I'm not aware of leaked clear data. Fanthom's comprehensive (full-media) solution seems better conceived than my simple hack; I wonder if his solution could work with writable changes if the crypto-loop-like solution were dm-crypt instead of the older cryptoloop from 'losetup -e'. I have a theory that the device-mapper infrastructure may be more compatible with slax's need to seek into decompressed streams. I believe dm-crypt is the preferred modern way to do what was historically done with cryptoloop (now obsolete?)
First make a suitably sized container for your encrypted homes, 999 megabytes should be way too big, unless you store a gigabyte of stuff in your encrypted home directory. The container is filled with noisy random data, and I'll call it 'neighborhood.iso' since that's where home directories go. 'sdb1' is my slax USB stick, change the command to your proper device. # time ( nice dd if=/dev/urandom of=/mnt/sdb1/slax/neighborhood.iso bs=1M count=999 ; sync )
Since I make new loop devices all the time I made a script from jayflood's code, I call it /usr/local/bin/makeloop and this system depends upon it. When it's invoked it creates the next free loop device and returns the loop device number: #!/bin/bash
# makeloop: make a new loop device
# here I left out the step where I mount the encrypted volume and copy my user's home directory into it.
# The home directory (folder) is at the top level, so the container can contain multiple home folders
# unmount everything and clean up
# cryptsetup luksClose crybaby
# losetup -d /dev/loop24
# rm /dev/loop24
Now lets look at the code root will use to mount the encrypted home directory container, '/usr/local/bin/mountcrybaby' (that's mount crypto-user): #!/bin/sh
# encrypting swap might be a good idea, but implementation on live distro feels inappropriate
# so just disable swap to prevent clear data leaking into the swapfile
swapoff -a
if [ $? -ne 0 ]; then
echo "swapoff failed, you could leak clear data"
fi
if [ ! -e /tmp/neighborhood_image ] ; then
mkdir /tmp/neighborhood_image
chown crybaby:crybaby /tmp/neighborhood_image
chmod 750 /tmp/neighborhood_image
fi
LOOPNUM=`/usr/local/bin/makeloop`
LOOPDEV=/dev/loop$LOOPNUM
# check it out, this should find your encrypted container on any mounted device
# it will mount the alphabetically-last-one if it finds a bunch of encrypted containers
# this isn't great if your custom slax uses the 'from=' cheatcode to load from a custom directory
ISO=`ls /mnt/*/slax/neighborhood.iso | tail -n 1`
losetup $LOOPDEV $ISO
LOSETUP_RESULT=$?
if [ $LOSETUP_RESULT -ne 0 ]; then
echo "losetup $LOOPDEV $ISO failed: $LOSETUP_RESULT"
fi
cryptsetup luksOpen $LOOPDEV neighborhood_image
mount -o noatime /dev/mapper/neighborhood_image /tmp/neighborhood_image
Root could unmount the home directory container anytime it's not in use (ie when there's no logged in crypto-user), but we'll make the unmount happen automatically on system shutdown. Here's the unmount-crypto-user script, '/usr/local/bin/umountcrybaby': #!/bin/sh
if [ ! -e /tmp/neighborhood_image ] ; then
echo "umountcrybaby: nothing to do"
exit
fi
# gam_server survives inits runlevel related kill?
# the gam_server process can prevent clean unmounting
killall gam_server 2> /dev/null
# The following code shouldn't be necessary now that gam_server has been killed
if [ $UMOUNT_RESULT -ne 0 ]; then
echo "first umount /tmp/neighborhood_image failed"
umount /tmp/neighborhood_image
UMOUNT_RESULT=$?
fi
if [ $UMOUNT_RESULT -eq 0 ]; then
echo "umount /tmp/neighborhood_image success"
cryptsetup luksClose neighborhood_image
CRYPTSETUP_RESULT=$?
if [ $CRYPTSETUP_RESULT -ne 0 ]; then
echo "cryptsetup luksClose failed"
fi
fi
LOOPDEV=`losetup -a | grep "neighborhood\.iso" | awk -F : '{print$1}'`
if [ "$LOOPDEV" != "" ]; then
losetup -d $LOOPDEV
if [ $? -ne 0 ]; then
echo "losetup -d $LOOPDEV failed"
fi
rm $LOOPDEV
if [ $? -ne 0 ]; then
echo "rm $LOOPDEV failed"
fi
fi
rmdir /tmp/neighborhood_image
if [ $? -ne 0 ]; then
echo "rmdir /tmp/neighborhood_image failed"
fi
sync
Many kde applications keep working files (with readable clear data) in /tmp, and in stock form /tmp is not at all temporary in slax, it is saved with all other filesystem changes. I don't want to rebuild slax to change the default tmp behaviour, so I put the following code in /etc/rc.d/rc.local to change /tmp into a temporary filesystem: #!/bin/sh
# /etc/rc.d/rc.local: Local system initialization script.
### make the mount point
mkdir /mnt/tmp
### put a ram filesystem on the mount
mount -t tmpfs -o noatime tmpfs /mnt/tmp
### copy the old tmp contents so we retain present state
( cd /tmp ; tar cf - . ) | ( cd /mnt/tmp ; tar xf -)
( cd /var/tmp ; tar cf - . ) | ( cd /mnt/tmp ; tar xf -)
mount --move /mnt/tmp /tmp
rmdir /mnt/tmp
### bind overmount to replace original /var/tmp
mount --bind /tmp /var/tmp
Now let's make sure the encrypted volume is unmounted at system shutdown. This script is /etc/rc.d/init.d/crybaby #!/bin/bash
# This file is invoked from rc.sysvinit when starting runlevel 0 or 6
# and when these runlevels are started it unmounts the encrypted neighborhood image
if [ "$1" = "start" ]; then
/usr/local/bin/umountcrybaby
fi
You'll need to create some soft-links to this script in /etc/rc.d/rc0.d and /etc/rc.d/rc6.d so that the crypto-unmounter is started when init changes to runlevel 0 or 6 (poweroff and restart). These links must start with the letter 'S' and have '.sh' extention to be run as shell scripts: # cd /etc/rc.d
# ls -la */*.sh
lrwxrwxrwx rc0.d/Scrybaby.sh -> /etc/rc.d/init.d/crybaby
lrwxrwxrwx rc6.d/Scrybaby.sh -> /etc/rc.d/init.d/crybaby
I need to create a user that gets a home directory in the encrypted volume, this crypto user is 'crybaby' and his home directory is simply a softlink to a directory under a mount point in /tmp. Thus the crypto user doesn't even have a home directory until root has run 'mountcrybaby'. # cd /home
# ln -s /tmp/neighborhood_image/crybaby crybaby
Then add your crypto user to the password file and groups as normal, with his home directory as /home/crybaby
I have kdm set up to ask for login credentials before starting KDE. The way I usually work when I want to access or save encrypted data is to type 'control-alt-F6' at the kdm login to get a console, login as root, run 'mountcrybaby' and enter the LUKS password to decrypt the volume and mount it. Then I type 'control-alt-F7' to return to the kdm login where I can log in as crybaby. Everything in crybaby's home directory will be encrypted, so as long as your applications don't leak your clear data to locations outside your home directory you should be fine.
Since I just pointed someone at this thread, I thought I'd clarify a few things in the original post.
The part where I wrote this:
"Now I'll create the encrypted LUKS volume on my loop mounted neighborhood image"
You might note here that I manually retyped the salient parts of 'mountcrybaby" and 'umountcrybaby'. If you read ahead here and had already added those scripts to your system you could save a little work and you wouldn't have to manually customize the device number here (loop24).
Where I said this:
"here I left out the step where I mount the encrypted volume and copy my user's home directory into it"
That's because I didn't do that step here, I did it later after mounting the encrypted volume with the 'mountcrybaby' script. I did it a bit later because I hadn't created my user account or populated this home directory at this point. The order doesn't really matter. I prototyped this home directory the normal linux way as an unencrypted home directory before I moved it into the encrypted container.
A few other things from the first post could be clarified. Where I said:
"You'll need to create some soft-links"
I didn't actually give the command to create the softlinks, I just listed the directory to show that I had done that. The command is "ln -s" like in the next paragraph.
I didn't get into how you create users and groups on Slax because I always find this a little tricky. (!) For best Slax practices, a public module mustn't rewrite /etc/passwd since every module that did this would break every module that had done this before. Anyway, the salient commands are 'useradd' & 'groupadd', or you could use 'vipw', 'vipw -s', 'vigr', etc. Whatever commands you use, just make sure that /etc/passwd, /etc/group, and /etc/shadow are sane after your module is loaded. And KDE creates a whole lot of things in a user's directory the first time a user logs in. For all these reasons, I always have to iterate a bit before I have a new user account in a sane state before I put it in a module or container. This is probably why most Slax user's just use root (which I don't think is always the best idea, but it's fine for most slax usage).
I didn't really go into KDM setup either. KDM is KDE's login panel and can be found in the KDE menu under (System -> Control Center -> System Administration -> Login Manager). Personally, I hide all users except my 'guest' user. My guest user has a blank password, and is set to Auto-Login after 10 seconds. So if I want a priveleged user I login with a password, but if the system boots without intervention it automatically logs in as guest, and guest doesn't have priveleges to screw up the system or mess with other user's accounts.
My own personal module contains home directories for all the unencrypted users, password files, KDM customization, etc. So this solution is not exactly trivial, but I think now I've documented all the pieces. Anyway once the work is done it's just the one module plus the encrypted container added to slax.
I use slax a bunch of different ways, from USB, disk, CD etc. One feature of the 'mountcrybaby' script here is it looks for the encrypted containers on all your mounted devices, but only mounts the "last" one, which on my systems is always the removable devices. So if there's no container on USB, it will use the container it finds on a disk partition. But if I insert a USB before mounting the container, it uses the encrypted container on the mobile device. This is really handy; I always have a private data area on my machine, but it knows to favor the mobile area over the local area.
Finally, this technique is also useful to archive private data on a DVD. My encrypted container is included when I make my slax ISO image (/slax/make_iso.sh grabs it fine, just mind the size). The 'mountcrybaby' script finds the container on the DVD and mounts it just fine, but it does mean that crybaby's DVD home directory is read only and KDM won't succeed in logging in to a unwritable home. No sweat, log in as root and surf over to that user's read-only data. This is cool because I give my friends a standardish slax CD they can use, but if I use the DVD I have all my data, just for me.
Whew, hope that's useful to someone. I suspect there aren't many of us that create multiple user accounts on Slax, but there's no reason to be afraid of using Slax like a normal Slackware admin.
