public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Steinmetz <ast@domdv.de>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Oliver Neukum <oliver@neukum.org>, Pavel Machek <pavel@ucw.cz>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] zero disk pages used by swsusp on resume
Date: Mon, 11 Apr 2005 19:02:13 +0200	[thread overview]
Message-ID: <425AAD95.5000808@domdv.de> (raw)
In-Reply-To: <200504111839.50872.rjw@sisk.pl>

Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:
> 
>>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
>>
>>>Hi!
>>>
>>>
>>>>>Oliver Neukum wrote:
>>>>>
>>>>>>What is the point in doing so after they've rested on the disk for ages?
>>>>>
>>>>>The point is not physical access to the disk but data gathering after
>>>>>resume or reboot.
>>>>
>>>>After resume or reboot normal access control mechanisms will work
>>>>again. Those who can read a swap partition under normal circumstances
>>>>can also read /dev/kmem. It seems to me like you are putting an extra
>>>>lock on a window on the third floor while leaving the front door open.
>>>
>>>Andreas is right, his patches are needed.
>>>
>>>Currently, if your laptop is stolen after resume, they can still data
>>>in swsusp image.
>>>
>>>Zeroing the swsusp pages helps a lot here, because at least they are
>>>not getting swsusp image data without heavy tools. [Or think root
>>>compromise month after you used swsusp.]
>>>
>>>Encrypting swsusp image is of course even better, because you don't
>>>have to write large ammounts of zeros to your disks during resume ;-).
>>
>>Not only is it better, it completely supercedes wiping the image.
>>Your laptop being stolen after resume is very much a corner case.
>>You suspend your laptop while you are not around, don't you?
> 
> 
> Not necessarily.  Some people use suspend instead of shutdown. :-)

Now here's what I'm currently doing:

I do usually suspend instead of shutdown. The suspend partition is the
only unencrypted swap partition and it is disabled during regular
operation so it is not used for regular swapping. Except for a small
boot partition without any valuable data all other partitions are encrypted.

The key for dm-crypt setup is stored on an ide flash disk which isn't
inserted during travelling and which is transported separately.

Now let's imagine the laptop gets stolen by an average thief which is
the most common case.Thief needs to know if the laptop is working
because thief wants to sell it so thief powers on the laptop.

swsusp resumes and with the encryption patch renders the suspend image
worthless. The suspend/resume script immediately checks for the presence
of the ide flash disk with the correct key (match is done against the
in-kernel dm-crypt key). If the ide flash disk is not present or if
there is a key mismatch the script shuts the system immediately down, so
the in-kernel key is lost.

The only way for the thief now to access any data on the disk is to come
back and steal the flash disk, too.

When the initrd feature pavel just notified me about comes from mm to
mainline one can additionally protect the swap partition used for
suspend with dm-crypt and collect the key at resume time via initrd.

In this case the disk is then not only protected against the average
thief but also against the professinal one as long as the flash disk is
secure.

And if the laptop is not stolen the encrypted suspend image prevents
against nasty surprises of sensitive data turning up on disk that should
never have been put there in the first place (oh well, but one needs to
suspend from time to time).
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

  reply	other threads:[~2005-04-11 17:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-10 13:13 [PATCH] zero disk pages used by swsusp on resume Andreas Steinmetz
2005-04-10 18:40 ` Oliver Neukum
2005-04-10 19:29   ` Andreas Steinmetz
2005-04-10 20:03     ` Oliver Neukum
2005-04-10 20:14       ` Pavel Machek
2005-04-11  3:23         ` Elladan
2005-04-11 10:14           ` Pavel Machek
2005-04-11  7:13         ` Stefan Seyfried
2005-04-11 10:37         ` Oliver Neukum
2005-04-11 16:39           ` Rafael J. Wysocki
2005-04-11 17:02             ` Andreas Steinmetz [this message]
2005-04-11 21:27               ` Rafael J. Wysocki
2005-04-12 10:08                 ` Andreas Steinmetz
2005-04-11 14:18         ` Jan Niehusmann
  -- strict thread matches above, loose matches on Subject: below --
2005-04-10 15:03 Pavel Machek
2005-04-10 15:15 ` [PATCH] " Andreas Steinmetz
2005-04-10 18:18   ` Pavel Machek
2005-04-10 18:45     ` Oliver Neukum
2005-04-10 18:56       ` Pavel Machek
2005-04-10 19:33     ` Andreas Steinmetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=425AAD95.5000808@domdv.de \
    --to=ast@domdv.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox