RE: mlock(1)

• Previous message: Dave Hansen: "Re: get_user_pages() still broken in 2.6"
• In reply to: Andrea Arcangeli: "Re: mlock(1)"
• Next in thread: Jon Masters: "Re: mlock(1)"
• Reply: Jon Masters: "Re: mlock(1)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: "'Andrea Arcangeli'" <andrea@novell.com>
Date:	Tue, 28 Sep 2004 16:26:16 -0700

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
On Behalf Of Andrea Arcangeli
Sent: Tuesday, September 28, 2004 3:15 PM
To: Robert White
Cc: 'Nigel Cunningham'; 'Alan Cox'; 'Chris Wright'; 'Jeff Garzik'; 'Linux Kernel
Mailing List'; 'Andrew Morton'
Subject: Re: mlock(1)

> On Tue, Sep 28, 2004 at 03:03:44PM -0700, Robert White wrote:
> > (Stupid Idea Warning... 8-)
> >
> > The top-n reasons (mentioned) to want to have your swap encrypted involve things
> > like
> > dealing with a stolen/sold drive or someone using a boot CD to peak into your
> > swapped

> The stolen/sold drive is a subset of the stolen/sold laptop/desktop
> instead. In such case they would get access to all your hardware info.

If you are concerned about the stolen laptop scenario you would use the (theoretical)
boot block that required a boot/restore password, or read the password out of your
bios or something. No zero-password/pass-device restore has any right to be expected
to be any more secure than walking away from a running console. So if you suspend
your computer with you X sessions running and your screen unlocked, when you restore
you will be left just as exposed as if you just walked away from the running box
anyway. If your X session (whtever) is smart enough to note the passage of time and
ask for a password then that is exactly how safe you will be, but the computer *was*
just restored. [yes, I know I am missing part of your point in the above, hence the
below... 8-)]

As stated, the idea is pretty basic, but if you have a computer you are worried might
be stolen and compromised at this level, you presumably have set your bios passwords
and such. If the "non-time" section of the bios config ram is one of the composition
key elements, the act of clearing the bios to clear the boot password would
invalidate the data that the key generation block uses to recreate the key.

If you use a restore-password block because you are even more paranoid, then they
would need that password.

A "normal" investigator using a normal level of attack would be thwarted.

It's like your house keys, you house is secure unless someone steals your keys... So
sure, someone could prep a special program to compromise the default boot block by
siphoning out the meta-boot-block data, the bios config data, the CPU ID, and root
file system GUUID, the boot command line, and the clock serial number and recreate
the cryptoswap key and then rig up a special swap probe program or specialty kernel
to run the restore etc if they new to do this first-thing (e.g. if they stole the
laptop or computer with the express intent of doing this so they didn't even try to
boot it once before beginning the attempt) but if they did this, you have a bigger
problem than having your laptop stolen... 8-)

But for that "casually" stolen laptop or computer, if they boot from a CD (having
this mecanisim) or use alternate boot parameters, or restore once and the hit the
power switch because they couldn't trigger the suspend, the swap image is scrambled.
If they use the system "vergin", without changing a thing, then they will get your
normal boot, which is no more or less secure than you have set it up to be via the
front door services (login. FTP, etc).

If they steal your server computer (that never goes to suspend because it is your
server) and they can't trick it into suspending itself first (e.g. they pull the plug
and run with it) then the key generator block was never written from ram to swap, so
your swap was "completely encrypted" because, while they have all your static IDs and
configurations they *don't* have the entropy value that was used to write the swap
image because the meta-boot-block was never written to anything, and again you are
only as exposed as the rest of your security has left you.

I know it is all kinds of not-perfect, but it *is* extensible and it is pretty darn
good.

And being extensible, you could have your very-own secret, home-made
key-generation-block template that you wrote yourself that nobody else in the world
knows about and makes restore (swap decryption) predicate on anything your heart can
envision and you can provide in a timly manner during startup... Like the
super-secret RFID tag in your favorite pair of wall-mart sneakers.

Also, the attacker gets only one chance not to screw up because the non-decrypt
startup sequence destroys the original key generation block and reinitializes the
swap headers. (Yes, he could save the swap image and try again but that is a long
brute-force cycle. 8-)

So it is not perfect, and I suspect it could be rendered even better by the thoughts
of other/better crypto types than myself (e.g. most anybody 8-), but I think you will
find it a lot more secure than you might think after just one read.

Rob White,
Casabyte, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

• Previous message: Dave Hansen: "Re: get_user_pages() still broken in 2.6"
• In reply to: Andrea Arcangeli: "Re: mlock(1)"
• Next in thread: Jon Masters: "Re: mlock(1)"
• Reply: Jon Masters: "Re: mlock(1)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]