I have a USB flash drive with Full Disk Encryption using LUKS. I plugged in the drive and mounted it as such using the following:

cryptsetup luksOpen /dev/sdb flash
mount /dev/mapper/flash /mnt/flash

If I physically remove my flash drive I can still access it's contents at /mnt/flash. Why is this? I see it as a security risk as I want my flash drive contents to become inaccessible as soon as the drive is physically removed.

What can I do to make this happen? It needs to be something I can do to the drive as I use this on other computers and I don't want to have to change them all to make the drive secure.

  • Could be just a few cached files & entries. How much data can you actually read/copy? After flushing the disk caches can you still read anything? ps. you'll probably corrupt the filesystem if it was mounted rw by yanking it out – Xen2050 Aug 23 '17 at 12:25
  • Well my SSH private key is on there, and I can still use it to authenticate via SSH to other machines. Desirable behavior would be that if it was removed the key would not remain usable in RAM. – Patrick Aug 23 '17 at 12:34
  • 1
    Interestingly, I think the data may remain in ram even after cleanly unmounting & luksClose & removing it, it just might be marked as "free", not unlike deleting a file. But unmounting first sounds like your answer, even a quick alias or desktop shortcut or something to click. Or, write a program/script that looks for the device every so often, and tries to umount it if it's missing. Or, switch off all the power after pulling out the usb (or before, wouldn't matter) would ensure nothing's easily accessible. – Xen2050 Aug 23 '17 at 12:47
  • "Or, write a program/script that looks for the device every so often, and tries to umount it if it's missing. " That seems like a great solution, actually, Thanks! – Patrick Aug 23 '17 at 14:29
  • 1
    Sorry, I thought I gave you a +1, I just did now. :) – Patrick Aug 24 '17 at 13:20

If you ran a program / script from the USB itself, you should be able to figure out what LUKS map/name and device it's on (or just tell the script the device or mapped name if you know it) and watch for when the device "disappears" when it's removed. Then unmount it.

I'm pretty sure that unplugging a USB will cause the device (/dev/sdXn) to disappear, but in case it doesn't you'd have to watch dmesg or look in the syslog, or find it somewhere in /sys perhaps.

Here's a proof-of-concept bash script that looks like it should work, but I don't have any LUKS partitions on usb's to test with, so I'm not sure if umount might need options like --lazy or --force.

map=$( df --output=source $PWD |tail -n1 )

device=$( sudo cryptsetup status "$map" | grep -o "device:.*"|cut -d' ' -f 3 )

while [ -b "$device" ]
    sleep 30

echo "Device $device is missing, unmounting"
sudo umount -v "$map"

If it's run from inside the mounted LUKS container, $PWD should find the LUKS name it's mapped on, and then the device, and if the device stops being a block special file then unmount the mapped device.

PS If the device was mounted rw (writeable) the filesystem can be corrupted by suddenly unplugging it. FAT seems especially vulnerable, while a journaling filesystem should be more robust. If it's mounted ro (read-only) at least you could avoid that problem, mount accepts -o ro and cryptsetup accepts --readonly (both probably aren't necessary)

|improve this answer|||||

You seem to be skipping some steps in the process. You should:

  • Insert the drive
  • cryptsetup luksOpen /dev/sdb flash
  • mount /dev/mapper/flash /mnt/flash
  • Use the drive as normal
  • umount /mnt/flash
  • cryptsetup close flash
  • Remove the drive

The inverse of mount is umount. Trying to umount a non-inserted drive may hang, depending on what the system is trying to do. The cryptsetup close step further removes the drive's mapping and wipes the encryption key from kernel memory.

You cannot guarantee that all (meta-)data is properly written to the device if you physically remove it without calling umount. Your encryption key is still available in memory until you call cryptsetup close. With that in mind, these steps should not be skipped.

|improve this answer|||||
  • Right. I understand that it shouldn't be removed without properly closing and unmounting. But in this scenario is there a failsafe I can use to ensure that the drive automatically unmounts or cryptsetup closes the drive upon the drive physically being removed? I have my SSH key on here and I don't want it accessible after I remove the drive if I don't unmount properly. – Patrick Aug 16 '17 at 2:53
  • @Patrick After removing a drive, you can try a umount -f to force an unmount (but this has a chance to hang), or umount -l to at least make the files inaccessible until a real unmount can occur. – Fox Aug 16 '17 at 3:06
  • That'll have to do. I was hoping there was an automated way... – Patrick Aug 16 '17 at 3:11
  • How could a savagely unplugged drive be unmounted auto[mg]atically after the fact? Even Windows can't do it (hence the tray icon)! If you're using a GUI, you can umount the drive from a file manager like Nautilus before unplugging the drive, way easier than using the command line, you can also mount your drive from a file manager. – cylgalad Aug 16 '17 at 7:46
  • @cylgalad My comment was only meant to imply "make the file tree inaccessible" rather than a true unmount – Fox Aug 16 '17 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.