<div dir="ltr">On Wed, Dec 16, 2015 at 11:14 AM, Nick Rhodes <span dir="ltr"><<a href="mailto:nick@ngrhodes.co.uk" target="_blank">nick@ngrhodes.co.uk</a>></span> wrote:<br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the info Rob.<br>
<br>
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.<br></blockquote><div><br></div><div>(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...)<br></div><div><br></div><div>AIUI (please jump in if they have this wrong) these all just wrap dmcrypt in various (distro-specific) ways. <br><br>Do Debian etc now use session keys to encrypt swap and /tmp ...?<br></div><div><br><br></div><div>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. <br><br>Of course, systemd may make this impossible without hacking C code but I run Gentoo so I wouldn't know :-)<br><br></div><div>(Cue usual rants about The One Ring^H^H^H^HInit SystemD To Rule Them All)<br></div><div><br></div><div>(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) <br><br>(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...)<br></div><div><br></div><div>(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...)<br></div><div><br></div><div>Robert<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers, Nick<br>
<div><div class="h5"><br>
> On 16 Dec 2015, at 09:47, Robert Burrell Donkin <<a href="mailto:robertburrelldonkin@gmail.com">robertburrelldonkin@gmail.com</a>> wrote:<br>
><br>
> Bit of a long email...<br>
><br>
> If you're going to read just one line make it this: session encrypt your swap and /tmp for 2016!<br>
><br>
> ...<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 4. dmcrypt and cryptsetup LUKS are great and easy to use.<br>
><br>
> 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]<br>
><br>
> 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.<br>
><br>
> 7. Use a long passphrase wiht plenty of entropy to protect the encrypted root partotion.<br>
><br>
> 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...<br>
><br>
> Robert<br>
> [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.<br>
><br>
> [2] Here's my dmcrypt for Gentoo<br>
><br>
> ## swap<br>
> # Swap partitions. These should come first so that no keys make their<br>
> # way into unencrypted swap.<br>
> # If no options are given, they will default to: -c aes -h sha1 -d /dev/urandom<br>
> # If no makefs is given then mkswap will be assumed<br>
> swap=crypt-swap<br>
> source='/dev/sda2'<br>
><br>
> ## Tmp<br>
> # Encrypted with random key<br>
> target=crypt-tmp<br>
> source='/dev/sda3'<br>
> options='-d /dev/urandom'<br>
> pre_mount='/sbin/mke2fs ${dev}'<br>
> post_mount='chown root:root ${mount_point}; chmod 1777 ${mount_point};'<br>
><br>
</div></div>> _______________________________________________<br>
> Bradford mailing list<br>
> <a href="mailto:Bradford@mailman.lug.org.uk">Bradford@mailman.lug.org.uk</a><br>
> <a href="https://mailman.lug.org.uk/mailman/listinfo/bradford" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/bradford</a><br>
<br>
<br>
_______________________________________________<br>
Bradford mailing list<br>
<a href="mailto:Bradford@mailman.lug.org.uk">Bradford@mailman.lug.org.uk</a><br>
<a href="https://mailman.lug.org.uk/mailman/listinfo/bradford" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/bradford</a><br>
</blockquote></div><br></div></div></div>