public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Ford <david@blue-labs.org>
To: Marty Poulin <mpoulin@playnet.com>
Cc: David Lang <david.lang@digitalinsight.com>,
	Ben Ford <ben@kalifornia.com>,
	David Wagner <daw@mozart.cs.berkeley.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: summary Re: encrypted swap
Date: Thu, 09 Aug 2001 00:56:31 -0400	[thread overview]
Message-ID: <3B7217FF.3060104@blue-labs.org> (raw)
In-Reply-To: <Pine.LNX.4.33.0108071957170.3450-100000@dlang.diginsite.com> <3B70E4C8.2020400@blue-labs.org> <041d01c1205a$5afd9c00$0b32a8c0@playnet.com>

Encrypted swap isn't a complete solution either.  As systems continue to 
evolve and processes begin to share space across machines or migrate to 
other machines, the data becomes visible in one medium or another.  Due 
to the penalty incurred with encrypting swap or a like solution, the 
cost is prohibitive as a general solution.

Two means to minimize this cost are (a) in userspace encrypt the data 
before leaving it stored in memory or (b) have a flag that marks a given 
page as _PAGE_ENCRYPTION so that only that page is encrypted while the 
rest of the pages are left alone.

The first solution is userspace only and portable across all other 
mediums.  The second solution minimizes cost at the granular level of a 
page boundary.

In any given case, physical access renders most solutions void or 
significantly paled.  I am not however of the opinion that the concept 
should be dropped.  I firmly believe in layered security, not a 
one-stop-solution.  That is to say that I will layer thin or weak 
security just as I would add heavy security.  Simply making your data 
look uninviting is sufficient to drive away most would-be's.

David

Marty Poulin wrote:

>>You can't guarantee much if the machine is physically compromised.  In
>>the situation of wiping, you probably won't need swap immediately after
>>boot so you can afford to execute a script that wipes the file/partition
>>then mounts it.
>>
>>It's all easily accomplished in userspace.
>>
>>David
>>
>This all depends on what the circumstances are.  If you are talking about
>someone being able to walk up to the machine while on and pull the memory
>cards, nope we cant stop that with the OS.
>
>That is not what we are trying to do, one of the specific scenarios was the
>example of a notebook computer that either was shut off quickly or freezes.
>If this notebook is stolen before the system is rebooted presto the crook
>has access to everything in the swap.  All he has to do is take out the
>drive and put it in another system.
>
>The solution to that is encrypted swap.
>


  reply	other threads:[~2001-08-09  4:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.g4fleqv.1mle133@ifi.uio.no>
2001-08-07 21:34 ` summary Re: encrypted swap Ted Unangst
2001-08-07 21:39   ` David Spreen
2001-08-08  0:43   ` David Wagner
2001-08-08  3:30     ` Ben Ford
2001-08-08  2:59       ` David Lang
2001-08-08  7:05         ` David Ford
2001-08-08 22:34           ` Marty Poulin
2001-08-09  4:56             ` David Ford [this message]
2001-08-09  5:02               ` David Wagner
2001-08-09 15:29                 ` Andreas Dilger
2001-08-09 20:31               ` EOT " Rik van Riel
2001-08-09  0:19           ` David Wagner
2001-08-08  4:58       ` David Wagner
     [not found] <fa.fk6d0vv.vgmm1i@ifi.uio.no>
2001-08-08  5:37 ` Ted Unangst

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=3B7217FF.3060104@blue-labs.org \
    --to=david@blue-labs.org \
    --cc=ben@kalifornia.com \
    --cc=david.lang@digitalinsight.com \
    --cc=daw@mozart.cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpoulin@playnet.com \
    /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