duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] PASSPHRASE, the environment, memory, etc.


From: Travis H.
Subject: Re: [Duplicity-talk] PASSPHRASE, the environment, memory, etc.
Date: Thu, 17 May 2007 19:46:48 -0500
User-agent: Mutt/1.5.12-2006-07-14

On Thu, Apr 12, 2007 at 07:07:25PM -0500, Charles Duffy wrote:
> Python can indeed alter its own environment via something like "del 
> os.environ['VARIABLE_NAME']". However, that won't help if the same 
> variable is in the environment of the parent process -- and it won't 
> necessarily guarantee that there aren't copies hanging around in memory.

Well, this is true of string objects; OTOH, the environment variables
are not stored like python strings (os.environ must be magic, since they
aren't even stored in the same area of memory) and so if you delete it from
there it should be gone.

Note that "ps -e" or an equivalent works on many systems to display
the environment, so it really isn't private at all.  Also, some
programs like telnet can be queried to give away environment variables
(suboption negotiation); I'd suspect the same of ssh possibly.

> (Python is garbage-collected, and unless you force a collection a copy 
> of the string object which has already been retrieved may still stick 
> around somewhere -- there are a bunch of other potential gotchas as well).

Yep.  This touches on a variety of other issues regarding data remanance;
it stays around in swap space, can burn into memory, can remain on disk
after deletion (possibly), and so forth.

What one really needs in a secure computer system is positive deletion
functionality, but so far nothing provides this.  Barring that,
complete encryption of everything on disk solves the disk and swap
remanence issue, but in-memory, things are still up for grabs.  Some
embedded systems might XOR passwords with a bit pattern for long term
storage to prevent burn-in, where you can flip bits in both
periodically to mitigate the physical changes caused by
electromigration.

You could use a buffer instead of a string, possibly, to avoid having
python sieze control of it, but your effort is probably better spent
elsewhere, or solving it once and for all in some kind of crypto
library.

Heck, I'm of the opinion that keys probably deserve a full-fledged
kernel subsystem for managing them since there are many low-level
issues.
-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- <URL:http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email address@hidden

Attachment: pgpZdyj2ssSap.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]