[Bradford] Data Cleanliness

Nick Rhodes nick at ngrhodes.co.uk
Wed Dec 16 11:15:15 UTC 2015


Thanks for the info Rob.

I’ve only skimmed this, you may have already mentioned, but Mint/Debian/Ubuntu all have user friendly full disk encryption available at install time that I use on all my mobile installs; this encrypts everything apart from /boot and is reliable and well supported.

Cheers, Nick

> On 16 Dec 2015, at 09:47, Robert Burrell Donkin <robertburrelldonkin at gmail.com> wrote:
> 
> Bit of a long email...
> 
> If you're going to read just one line make it this: session encrypt your swap and /tmp for 2016!
> 
> ...
> 
> 1. Encrypt swap and tmp on bootstrap with random session keys[1]. Wiping these reliably on shutdown is really tough (you'd need a second pivot root into an in-memory filesystem), so you have to expect that any data written to these partitions could be read by an attacker able to obtain root or physical access to the drive. Excepting data securely locked by the kernal, it's really really tough to ensure reliably that swap isn't used from time to time. Instead of trying to wipe on exit, instead use dmcrypt to block encrypt the partition using a random session key. Once the kernel stops running, to read /tmp and swap from disc requires recovering the session key. This key should be locked in memory by the kernel - but even if there happens to be a bug, it can only get written to swap. Whilst requires the session key to recover. Yes, an attacker able to obtain root after boot may be able to read /tmp and swap written during that boot session but not written during past or future sessions.
> 
> 2. If you're using Gnome, the secure dialog should grab keyboard, mouse and screen whilst you enter a passphase (ie you shouldn't be able to do anything but type into the box). If this doesn't happen then I doubt the kernel level locking code has been correctly called by the distro. Use a tty and ssh-agent instead.
> 
> 3. I haven't played around seriously with JNI for a few years, but I don't trust the kernel level memory locking gaurantees available via vanilla JNI. I believe that signed security extensions obey different rules, but yes bouncy castle doesn't hide any of the difficult details. JavaMail offers signing and encryption but I don't trust Sun to lock the memory correctly on Linux. 
> 
> 4. dmcrypt and cryptsetup LUKS are great and easy to use. 
> 
> 5. In particular, using cryptsetup to format disc images (in Linux, there are just files which you mount using lookback), copying over a home directory and then mounting over the home works well for me. (Sounds lame, but I now solve Ruby and JavaScript compatibility issues by creating new encrypted images for each endeavor.) This makes it really easy to reliably destroy/clean everything I've been working on for a particular client/project. This is really, really easy and gives great horizontal security[1]
> 
> 6. If you're running encrypted root, use key files for partitions you mount every time stored in /root. If an attacker obtained root on your box then they will be able to read the data on the partitions so there's little value in more sophisticated protection.
> 
> 7. Use a long passphrase wiht plenty of entropy to protect the encrypted root partotion.
> 
> 8. For email signing and encryption of important stuff (like releases) I don't trust X11. I boot into a different filesystem, do the signing and then shutdown. After my injury, I don't need to do this regularly any more. If I did, I'd use busybox and sqaushfs to build a micro in-memory distro and store that on a usb drive...
> 
> Robert
> [1] Even with read privaleges, an attacker would not only need to find out which image was of interest but also the key to open any which weren't currently mounted. This is a readonable way to protect from the sort of read-only-elevation attacks flash (and web browsers) are prone to.
> 
> [2] Here's my dmcrypt for Gentoo
> 
> ## swap
> # Swap partitions. These should come first so that no keys make their
> # way into unencrypted swap.
> # If no options are given, they will default to: -c aes -h sha1 -d /dev/urandom
> # If no makefs is given then mkswap will be assumed
> swap=crypt-swap
> source='/dev/sda2'
> 
> ## Tmp
> # Encrypted with random key
> target=crypt-tmp
> source='/dev/sda3'
> options='-d /dev/urandom'
> pre_mount='/sbin/mke2fs ${dev}'
> post_mount='chown root:root ${mount_point}; chmod 1777 ${mount_point};'
> 
> _______________________________________________
> Bradford mailing list
> Bradford at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/bradford




More information about the Bradford mailing list