public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Elladan <elladan@eskimo.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Oliver Neukum <oliver@neukum.org>,
	Andreas Steinmetz <ast@domdv.de>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] zero disk pages used by swsusp on resume
Date: Sun, 10 Apr 2005 20:23:40 -0700	[thread overview]
Message-ID: <20050411032340.GC9933@eskimo.com> (raw)
In-Reply-To: <20050410201455.GA21568@elf.ucw.cz>

On Sun, Apr 10, 2005 at 10:14:55PM +0200, Pavel Machek wrote:
> 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 ;-).

How does zeroing help if they steal the laptop?  The data is there, they
can just pull the hard disk out and mirror it before they boot.

The only way to improve security here is to encrypt it.  Zeroing will
help some if they compromise root later, but I doubt that's really worth
it considering you're screwed after a root compromise anyway.

-J


  reply	other threads:[~2005-04-11  3:24 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 [this message]
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
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=20050411032340.GC9933@eskimo.com \
    --to=elladan@eskimo.com \
    --cc=ast@domdv.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=pavel@ucw.cz \
    /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