Re: When scrubbing secrets in memory doesn't work

[Peter Watkins <peterw () usa net>]

On Mon, Nov 18, 2002 at 04:36:57PM +0000, Richard Moore wrote:
> Nicholas Weaver wrote:
> > On Thu, Nov 14, 2002 at 02:44:58AM -0800, Michael Wojcik composed:
> > The bigger concern is when the memory is paged to disk, and that
> > record may have a much MUCH longer time window.  But scrubbing has no
> > real effect on this

> It's worth noting that on systems such as linux and solaris, it is easy 
> to avoid the paging problem by locking the process into memory. This is
> accomplished using the system calls mlock(2) and mlockall(2).

Nice idea, except mlock() and mlockall() are only permissable when the 
effective userid is that of the superuser. (We touched on this a while back 
when discussing GnuPG; IIRC, in general Unix systems don't allow regular 
user processes to lock memory pages, while Windows' win32 API does allow 
such behavior.[0])

-Peter

[0] The good news is that win32 has a setting for allowing user processes
to lock pages that is distinct from the effective userid/gid; the bad news 
is that it's set per-user instead of per app; to allow users to run apps 
that insist on physical pages for memory allocation, it looks like you have 
to grant them the ability to effectively DoS the machine by grabbing all 
its physical memory. Oops.
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1099/win32/win321099.htm&nav=/msj/1099/newnav.htm

-- 
Peter Watkins - peterw () tux org - peterw () usa net - http://www.tux.org/~peterw/ 
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692