[Bradford] Data Cleanliness

Wed Dec 16 12:05:26 UTC 2015

On Wed, Dec 16, 2015 at 11:14 AM, Nick Rhodes <nick at ngrhodes.co.uk> wrote:

> 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.
>

(That hasn't been my experience. I stopped using full disc encryption on
Debian after a particularly rude maintainer of the boot scripts told me to
get stuffed after I'd spent three days debugging and discovering a patch
for their buggy upgrade script. In general, after that infamous Debian
idiot who broke the entropy pool I tend to start with low opinions of
Debian maintainers when it comes to security, which is too often in my
experience reinforced by organisational attitudes which emphasis political
viewpoints over technical compedence...)

AIUI (please jump in if they have this wrong) these all just wrap dmcrypt
in various (distro-specific) ways.

Do Debian etc now use session keys to encrypt swap and /tmp ...?

Using random session keys for swap and /tmp offers a significant
improvement in security and dmcrypt in the kernel makes this easy and
secure. Worth checking whether Debian et al are now offering this out of
the box, and if not then switch it on.

Of course, systemd may make this impossible without hacking C code but I
run Gentoo so I wouldn't know :-)

(Cue usual rants about The One Ring^H^H^H^HInit SystemD To Rule Them All)

(Also a good opportunity for those with active imaginations to think about
why systemd might wish to stop this, and whom might be in a position to
influence this)

(State actors tend to have access to physical measures, and root encryption
is vulnerable to key loggers embedded in the initram and stored in /boot.
session encrypting swap and /tmp reduces past and future data leakage once
the actor has a copy of the hard disc and the root encryption passphrase...)

(Not that I'm foolish enough to think I have any level of data privacy
against state actor, but what states were doing yesterday, criminals will
be able to do tomorrow...)

Robert

>
> 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
>
>
> _______________________________________________
> Bradford mailing list
> Bradford at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/bradford
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/bradford/attachments/20151216/b49f13c4/attachment.html>