[Bradford] Data Cleanliness
Robert Burrell Donkin
robertburrelldonkin at gmail.com
Wed Dec 16 09:47:29 UTC 2015
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};'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/bradford/attachments/20151216/73806578/attachment.html>
More information about the Bradford
mailing list