Date: Thu, 15 May 2003 09:24:25 +0200
From: =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de>
To: Yoav Weiss <ml-lkml@unpatched.org>
Cc: Ahmed Masud <masud@googgun.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: encrypted swap [was: The disappearing sys_call_table export.]
Message-ID: <20030515072425.GA7638@wohnheim.fh-wedel.de>
References: <20030514162323.GB16093@wohnheim.fh-wedel.de> <Pine.LNX.4.44.0305142152500.12748-100000@marcellos.corky.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Pine.LNX.4.44.0305142152500.12748-100000@marcellos.corky.net>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2036
Lines: 49

On Wed, 14 May 2003 21:59:47 +0300, Yoav Weiss wrote:
> On Wed, 14 May 2003, J?rn Engel wrote:
> > On Wed, 14 May 2003 12:13:03 -0400, Ahmed Masud wrote:
> > >
> > > The idea is to have encryption keys for the pages to be unique on a
> > > per-uid per-process basis. So one user on the system cannot access (even
> > > if they are root) parts of another's private data.  To achieve this,
> > > different parts of swap device need to be encrypted with different keys.
> >
> > How do user *know* that root cannot simply bypass this security?
> >
> > Root, god, what's the difference? ;-)
> 
> Aside from what Ahmed said about about rootless systems, the per-process
> encryption reduces the window of opportunity for attackers who gain root
> (or physical access).
> 
> Try strings(1) on your swap device.  You'll be surprised at what you find.
> You'll probably recognize passwords you haven't useds for a long time, and
> a lot of other stuff you didn't expect.  Sometimes you can find whole ssh
> sessions there, plaintext.  (think xterm scroll buffer).
> 
> With per-process encryption, even if root decides to read the swap at some
> point (evil admin or an attacker who 0wn3d the box), the leakage is
> limited to processes currently running.

s/currently running/running now or in the future/

But apart from that, it does really reduce the window, agreed.

An alternative approach would simply zero all freed memory in the
system, with almost identical effects. Almost means you are missing
memory (that isn't cleared on reboot on all systems, ...) and this is
missing hard disk recovery that can read data already overwritten.

Arguments against this simpler approach?

J?rn

-- 
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson 
-
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/