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

[Charles Duffy]

Neal Clark wrote:
> Thanks, never knew that. Do you know how this works on FreeBSD (w/o 
> procfs)?

No, I don't. Worst-case one needs to go through the local equivalent to 
/dev/mem or /dev/kmem -- but that's only if one is trying to do things 
the hard way (as opposed to redirecting subprocesses launch attempts, 
watching communication between components, and using a debugger to watch 
what's going on at any points where a password exists as a simple C 
string in a component which can be rebuilt to have debug symbols present).

> > By spreading sensitive knowledge across more systems (both the machine 
> > being backed up and the separate machine which stores the key used for 
> > encrypting the backups), you're increasing your overall exposure as 
> > well as adding more moving parts (and thus failure cases).
>
> I guess I could just keep the passphrase on the encrypted disk to solve 
> (or at least in some way address) the physical access vector, but I was 
> curious more about how the password 'hangs around' in the environment 
> and in duplicity itself. Like for example, could I automate a way to 
> fudge the environment duplicity executes in, like perhaps in the python 
> code, delete the environment variable after its been read into the 
> program? And also, is there anything I can do to 'secure' or what have 
> you the fact that the passphrase is in memory?

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. 
(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).

There are certainly obfuscation techniques available -- if you want to 
do some research on those, look into application copy protection, 
particularly from the point of view of the individual cracking it; 
that'll give you a good idea about what can be done and how it tends to 
be circumvented in practice.


Store the password on the encrypted section of the machine being backed 
up, secure root access (and access to the account running the backup 
process) with as much paranoia as you can muster, and be sure you're 
encrypting your swap space; I'm not sure I have much more to offer at 
this juncture.