This Time Self-Hosted
dark mode light mode Search

Tightening security

I’m not sure why is it that I started being so paranoid about security; quite a few things I’ve been changing in my workflow lately, and even though I kept a decent security of my systems and network, now I’m going one step further.

Beside working on getting Kerberos-strengthened NFS working (and trying to get libvirt if it wasn’t for gtk-vnc and the other mess), I’m now considering something to strengthen the security of this laptop. Given what I’ve seen with pam_mount, it would also make sense to get that improved, fixed, maybe even integrated with the pambase, as usual for me.

But beside not actually having an idea of how to configure that up yet, it also made me think of the use case for it. Let’s say I actually encrypt the whole partition (I know there are a few options for not using an entirely encrypted partition, but since last I checked they all require patched kernels, I’d like to stay quite away from those); it gets mounted when I login (on GDM), and up to that it’s okay, but what happens when I close the laptop in suspend? It wouldn’t get unmounted because all the process are still there. And if somebody can get a new login with that, well, you’re screwed because the other sessions can see the mounted partition as well.

One option I can think of is one old friend of mine: pam_namespace. This module allows to “split” the mount namespace of user login sessions at PAM login; placed before pam_mount, it would let the partition to appear mounted for all the processes starting from the process calling the module. What this can actually achieve is that even if you have root password, and create a new session with its credentials.. the partition will not appear to be mounted at all. Cool, but pam_namespace breaks a bunch of things such as HAL. It was almost exactly one year ago that I wrote about that.

Another option is to simply logout before suspending the laptop; this should also fix the graphic card reset problems: shut down X before suspending, reopen it with a new login afterwards. It take a bit more to reopen everything of course, but that’s not the main problem — it wouldn’t be a problem at all if software actually restarted as intended, like if Gnome actually restored the session and included Chromium tabs.

Unfortunately, I actually got one good reason to think that there is some trouble for what concerns this idea. One of the first incarnations of the tinderbox I found out that it actually let some stray processes; and this was by just executing a console-only chroot, as root, and without any desktop system software running. I’m quite sure that at least the GnuPG and SSH agent software is kept running at the end of the session. Such stray processes would still make it impossible to unmount the partition.

Finally the last remaining solution is to turn off the whole system, but as you probably already know that it takes time for a cold start to work out properly.

What options are there for these situations? Anybody have suggestions? I wouldn’t mind even just using an encrypted directory tree, mounted via FUSE, and encrypting with GnuPG (and thus, with my FSFe Fellowship Smartcard).

A similar, lower-priority but maybe even of more long-term importance is encrypting my backup data; in this case, I cannot be there to input the password over and over again, so I have to find a different solution. One thing I actually thought of is to make a (sane) use of the “software protection hardware keys” that I remember from computer magazines of the final ‘90s. There is actually a manufacturer of those not far from where I live, in the same city as my sister; I wouldn’t mind buying a sample USB key from them, and if they give out the details for communicating with it, implement an open source library to talk with that and see if I can make use it as encryption key for a whole partition.

At any rate, any suggestion so that I don’t have to reinvent, or at least redocument, the wheel, is as usual very welcome.

Comments 20
  1. Is there any reason you’re not encrypting your whole system?Using an encrypted root filesystem solves many, many, many security problems. You can hibernate the system instead of suspending; if you suspend-to-disk with an encrypted swap partition, you’re fine and need the passphrase/smartcard/USB token/whatever to start the computer up again.I recommend using LVM atop a dm-crypt/LUKS partition. Look for the XTS algorithm; I use aes-xts. XTS was designed from the ground up for block encryption and is not vulnerable to many previous attack vectors.On another note, I’m pleased you’re taking up some of the Gentoo Kerberos work. I’ve been trying with no success to get NFSv4/krb5p to work on Linux. It works *right out of the box* on OpenSolaris! A sad state of affairs. Thank you so much for looking at it.Whatever you end up doing, please let it have Heimdal support – Heimdal has been a more mature Kerberos distribution than MIT for quite some time, and still outpaces it feature-for-feature. I remember when the MIT Kerberos library wasn’t even thread-safe…

  2. Oh, another thing: the word for the hardware keys you’re talking about at the end there is “smartcards”. I’ve got a whole bunch of them lying around. They’re generally expensive and difficult to order in small quantities, but if you want a few (all the ones I have work with Linux, that’s a requirement), email me and I’ll ship you some.

  3. I really wouldn’t want to take my stakes at hybernation to be honest. For the kind of security protection I’m looking for, I don’t think I’m going to need full-system encryption, even if it would probably be possible to do if I were to use the integrated TPM on the laptop. As I said even being able to filter-crypt just a few files would be acceptable to me.Kerberos… it’s something I’ve been trying out; I have near to no experience on OpenSolaris, but I wasn’t able to get FreeBSD to talk with my currently setup NFSv4+krb5 … it works fine from Linux, even though just for my user without fallback to R/O for the portage user which is … tricky.Since I have just started with Kerberos, I sincerely don’t know the difference with Heimdal; I did notice that at least libvirt is supposedly working better with Heimdal than MIT, but iirc it’s pam_krb5 that does not work with Heimdal… and that’s a whole Pandora’s vase I’d rather not touch for now.Finally for what concerns smartcards, I actually have a couple; the FSFe Fellowship card is OpenGPG-based so it works only with GnuPG, but I got two PKCS#11 tokens, and I “described using them”:https://blog.flameeyes.eu/2… last year… I plan on finishing that support this year, if I can.But smartcards (usually) have a PIN-lock, what I was talking about is usually used for encrypting the license files, as such it has to work without PIN-locks.

  4. A few points:- Smartcard PINs are usually optional. Using a smartcard even without a PIN is still a “something you have” factor. It’s just no longer two-factor because you’ve taken out the “something you know”. If you need to not be present, I’d say use a smartcard with a program-supplied PIN. Be aware that with normal PKCS15 smartcards and most others you can have multiple “users” on the card at once, each with a potentially different PIN.- There are several different pam_krb5s. Last time I checked, Gentoo grouped different pieces of software together under the same name; some versions came from one place and some from another. Russ Allbery’s pam_krb5 from http://www.eyrie.org/~eagle… is what I use and works perfectly with Heimdal. Also works with PK-INIT (getting kerberos credentials from an SSL certificate, such as what you might put on a smartcard). It’s very cool to use your SC to get a Kerberos ticket.- On encryption: if you just want a few files and GPG isn’t enough, try using something like Truecrypt. You can do an `fuser -m` to see who’s using the filesystem and kill them, no?- You can do full-system encryption (except for /boot) even without a TPM/SC; just use a keyfile or password. Who cares if you “need” it? It’s one less thing to worry about, and the only cost is CPU time. All my systems these days are fully encrypted.

  5. Gentoo uses Russ Allbery’s pam_krb5 (as opposed to Red Hat’s).I am also more comfortable with heimdal. Problem is that openssl did not support heimdal last time I checked.On a related note, I feel that a lot of people blow kerberos out of proporton. It is an authentication mechanism and nothing more. If you are in an enterprise setting with a mix of systems (microsoft, linux, *bsd etc) and you want something better than username/password, fine. But otherwise, please consider if you are unneccesarily complicating your setup.For the original question, it is rather difficult to answer without knowing your thread model and what you are trying to protect. But if it is against stolen laptop or similar, truecrypt/cryptsetup with passphrase protected keyfiles (on usb stick or similar) and/or smartcards (especially for desktops) are popular choices. We do not use whole disc encryption but, again, depends (doesn’t it always? 🙂 ).

  6. Did you have a look at encfs: http://www.arg0.net/encfsThis would be the “mount directory tree with fuse” option. The nice thing is that the files are encrypted individually, so no need to set aside space for an encrypted partition and you could just backup the encrypted tree.

  7. Backups: use Duplicity. Or do what it does: encrypt the backup asymmetrically, with your public PGP key.

  8. After being positivitely surprised when I did my last eix-sync and read my Gentoo News, I expected to see a blog post from you regarding –as-needed now being in the default profile for Gentoo =)Congratulations! I’m looking forward to seeing a little post from you regarding it.

  9. For the encryption part, just have everything in an luks encrypted lvm (except /boot) and use hibernation. The easiest and most effecient solution with little to no performance difference.

  10. The one problem with ecrypt/encfs is that afaict they all require a special kernel patch to work, where I would prefer something FUSE-based…And again, I’m not sure I want to encrypt the whole system: encryption require CPU, and CPU on a laptop means battery, and at least some things (@/var/tmp@) would make sense to stay _out_ of encryption)…But I’ll look more about using PKCS#15 tokens to use for encryption, might actually find something useful there.

  11. I now use a luks cryptsetup for my backup and media disk:→ http://en.gentoo-wiki.com/w…Mounting is:gpg –decrypt /path/to/diskkey.gpg 2>/dev/null | sudo cryptsetup luksOpen /dev/sdX enc && sudo mount -t ext3 /dev/mapper/enc /mnt/disk && sudo mount -o bind /mnt/disk /path/to/mountpointsince I’m lazy, it’s a bash alias :)For security relevant files I’d do the same, but on a USB stick. For the really paranoid: On a micro-SD card (but beware of the microsd-to-USB adapters: mine tend to lose data, which is a real showstopper for encryption).The performance hit is 30% when watching movies on my poor old singlecore amd64, though.

  12. I’ll have to look into all the alternatives then… something might come up.I’m still bothered by the inability to separate the namespaces though.

  13. A possible solution (which I haven’t tried) that _doesn’t_ expose the filesystem while _not_ requiring you to shutdown your applications (no unmounting necessary). Just a basic layout of the procedure, no exact commands given.For more info, read “this article I wrote”:http://smorgasbord.gavagai…. – it uses the same tricks.This is what I propose.*Suspending*:# Have homedir on dm-crypt block device# Have loop device of same block layout as dm-crypt device ready, backed by sparse file (so can be 0 bytes if you want)# Drop all caches and use ‘dmsetup suspend’ to freeze your homedir block device. Use ‘dmsetup load’ to replace the backing block device of your homedir with the “fake” loopback device. Blocks won’t contain the right information and your apps will crash if you’d let them resume at this point. So let’s not do that.# Remove the dm-crypt mapping for your homedir partition.# At this point your files are an opaque encrypted blob (the dm-crypt base device), while your processes are still up (bot not running).*Resuming*:# recreate your dm-crypt block device: re-enter passphrase etc.# ‘dmsetup load’ to replace the dummy loopback-based block store with the real thing# ‘dmsetup resume’It is a very involved solution, a hack on the block layer, using infrastructure in ways it wasn’t meant for, but it does what you want.It would be nice if I could find a way to suspend an ecryptfs-filesystem and remove its key, to later re-add that key and subsequently resume the ecryptfs-filesystem.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.