Re: mlock(1)

[Andrea Arcangeli <andrea@novell.com>]

On Mon, Sep 27, 2004 at 04:34:54PM +0200, Stefan Seyfried wrote:
> That's fine for the never-enter-a-password case, but for the 
> suspend-case, it's not so good since i want to close the lid and pack 
> away the notebook. Two scenarios, two implementations.

Your "close-lid with suspend-to-disk" without ever asking password in
suspend is fundamentally unfixable, unless you use public key
encryption, but for it to be secure you've to store in your brain and
type >128 chars at every resume...

Probably the next best thing you can do is to ask a preventive suspend
password during boot, for the suspend-capable-machines. That would be
more reasonable since I'd leave it disabled on my desktop.

> Well, as long as you need your entire $HOME or / encrypted, it's not 
> easy. If you just need e.g. /secret/ encrypted userspace could umount it 
> before suspend and remount it after resume (we also lock X etc, adding a 
> umount / mount should be trivial).

losetup -d would probably do the trick if it clears the buffer where the
password sits before the kfree (that should be checked, not obvious that
it does it).

But it's not secure anyways without encryption since the memory freed by
mozilla where the credit card was, could be dumped into the swap space
if it was only partially reused as slab etc.. I mean, even normal
swapping is insecure on a laptop, but suspend make it worse.

the "freed" memory in linux can always contain sensitive data, and we
guarantee to never make it visible to anyone, and you're safe after you
shutdown the machine and the ram loses power. Good applications using
mlock should always clear the memory before releasing it to the
operative system, but most apps don't even use mlock and they relay on
the OS to be secure (and even the ones using mlock may not always clear
it before freeing it, even the oom killer could break that assumption).