duplicity shows sensitive data in process listing

[edso]

If credentials are given in the command line url parameter these show up in 'ps'

e.g.

/usr/bin/duplicity --verbosity 4 --encrypt-key FD3846C2 --sign-key FD3846C2 --gpg-options= --exclude-globbing-filelist /root/.duply/bkp/exclude /backup/ ftp://<user>:<PASSWORT>@<backupserver>/backup

suggestion is to introduce env vars URL_PASSWORD/URL_USERNAME and to keep FTP_PASSWORD for ftp backend only and backward compatibility. The fact that FTP_PASSWORD can be used with nearly all backend is afaik not documented. Even so duply 1.5.1.4+ will use it until this bug is resolved.

for the future a config file based auth as mentioned in
http://lists.gnu.org/archive/html/duplicity-talk/2010-01/msg00032.html
could make sense.

.. ede

[Peter Schuller (scode)]

Note that environment variables are not private either (try ps auxwwwe).

[edso (ed.so)]

i just checked on suse linux 11 and it seems that 'e' parameter for 'ps' shows only the environment vars of your own processes.
It showed nothing when logged in as a different user and duplicity was running as the first user.

..ede

[Peter Schuller (scode)]

> i just checked on suse linux 11 and it seems that 'e' parameter for 'ps' shows only the environment vars of your own processes.
> It showed nothing when logged in as a different user and duplicity was running as the first user.

Hmmmmm, okay. I'd have to re-check. I did a quick test but didn't
check processes belonging to user users. But I'm pretty sure that I've
read about env variables not being considered safe, for example for
GPG passphrases.

Possibly it depends on OS. Hmmmm.

<googles>

http://lists.gnupg.org/pipermail/gnupg-devel/2003-January/019607.html

It's very very possible this is just changed in practice on Linux
systems. But I'd be surprised if one can strictly count on it. But
certainly I'm sure it's better than passing secrets on the command
line. I did test it on FreeBSD 8 and it seems I cannot see other
user's envs there either.

--
/ Peter Schuller

[edso (ed.so)]

just found

http://archive.cert.uni-stuttgart.de/suse-security/2005/11/msg00001.html

and follow ups .. and agree. It's an architectural flaw to rely on the security of an environment. Therefor the right way to solve this would be to read a credentials file or to cat/pipe the credentials into the application (like gpg or smbclient do).

Ergo we're stuck with the config file approach I think.

..ede

[edso (ed.so)]

here is some background for open solaris

http://hub.opensolaris.org/bin/view/Community+Group+arc/passwords-cli

which also suggests the use of files.

..ede

[edso (ed.so)]

just some update:

some revisions ago the manpage was updated and now tells users to prefer FTP_PASSWORD over password in url, because it is supported by most backends and inherently safer than the inurl variant.

the suggestions above are still pending (generic vars and config file).

ede/duply.net

[Raphaël Droz (raphael-droz)]

It seems to be the occasion to support the ~/.netrc file like do most of ftp credentials consumers (ftp, lftp, wget, fetchmail, msmtp, ...)

[Eugene Crosser (crosser)]

It is generally considered more secure to keep passwords in the files, and never put them in the command line or environment variables because they are publicly exposed in many flavors of UNIX. .netrc seems to be the most appropriate way.

[edso (ed.so)]

correct.
using '.netrc' or file based authentification for backends that use clients or python code supporting a file based auth is totally possible already.

..ede/duply.net

[Eugene Crosser (crosser)]

Right now, duplicity (0.6.19) insists on asking the password if it was not specified in the URL or FTP_PASSWORD environment variable, even if lftp (which I use) is happy with the data present in .netrc.

[edso (ed.so)]

On 08.06.2012 13:33, Eugene Crosser wrote:
> Right now, duplicity (0.6.19) insists on asking the password if it was
> not specified in the URL or FTP_PASSWORD environment variable, even if
> lftp (which I use) is happy with the data present in .netrc.
>

can't you just simply set an empty password? ..ede

[Eugene Crosser (crosser)]

No, if it's empty duplicity will prompt for it. Which is exactly the problem that needs fixing.

[edso (ed.so)]

On 08.06.2012 14:45, Eugene Crosser wrote:
> No, if it's empty duplicity will prompt for it. Which is exactly the
> problem that needs fixing.
>

actually this would need a different bug report as it is not covered by "duplicity shows sensitive data in process listing"

also i am not sure this is worth the trouble as setting an env var is essentially as safe as using .netrc on most platforms providing the script/crontab where it's set in has correct files system permissions to be protected.

a. could you open a new bug please?
b. suggest in the new topic a way to solve this from your point of view? keep in mind that duplicity is supposed to be usable interactively as well (restoring on a new machine etc.), so the password prompt generally makes sense. how about checking for existence of FTP_PASSWORD and prompt if it's not defined?

..ede/duply.net

[Eugene Crosser (crosser)]

I would argue that exposing the password in an environment variable is almost as bad as in the command line ("it's safe on most platforms" is not good enough).

I cannot suggest a solution that would work well for all backends... It might be useful to have a separate method to provide the password by giving duplicity the filename that contains it. E.g. via a different environment variable, or via a command-line option ("duplicity --pwdfile=/etc/backuppwd ..."). However this won't help if the backend is a separate executable and has to have the password in the command line or environment variable - it will still be exposed via /proc. For builtin backends, this looks like a decently good solution.

[den (space-trip)]

I would like to use gkeyring. At the moment I do this...

export PASSPHRASE=`gkeyring.py --id 53 -o secret`

[edso (ed.so)]

Den:
 if your up to it this can definitely built into duplicity. so don't hesitate.

Eugene:
 correct. file based auth is the option targeted. unfortunately nobody tackled it so far.
 wrt. your empty FTP_PASSWORD issue.. just checked the corresponding source and it should only come up with a prompt if FTP_PASSWORD wasn't defined at all in a recent duplicity. can you confirm this?

..ede/duply.net

[Eugene Crosser (crosser)]

edso:
I have .netrc, and when I run lftp directrly it works without asking the password.

When I unset FTP_PASSWORD and run duplicty, duplicity asks for the password.

When I set FTP_PASSWORD="" and run duplicity, duplicity does not ask for the password, but lftp does! This is because lftp "forgets" all about .netrc at the moment when it's given the "user" command. Which is included in the batch that is given by duplicity to lftp in the -c option. I also noticed that if the username is not included in the duplicity url, the username given to lftp is the literal string "None" which looks rather wrong.

I could suggest, when username is not specified in the duplicity URL, to *not* include the "user" command into the batch. This should make lftp magically work if you have correct .netrc.

[edso (ed.so)]

if your willing to test it:

- locate duplicity/backends/ftpsbackend.py of your duplcity installation
- open with editor
- locate line ca. 83

os.write(self.tempfile, "user %s %s\n" % (self.parsed_url.username, self.password))

- edit and add one line in front of it and indent the original line by 4 spaces

if self.parsed_url.username:
    os.write(self.tempfile, "user %s %s\n" % (self.parsed_url.username, self.password))

does it work?.. ede/duply.net

[Eugene Crosser (crosser)]

Change as in comment #18 makes it work without asking the password.
(Must use the URL in the form "ftps://host/path" and have the entry in .netrc for that host).

[edso (ed.so)]

On 17.11.2012 22:47, Eugene Crosser wrote:
> Change as in comment #18 makes it work without asking the password.
> (Must use the URL in the form "ftps://host/path" and have the entry in .netrc for that host).
>

uploaded a branch
https://code.launchpad.net/~ed.so/duplicity/lftp.netrc
will probably end up in the next release..

thanks ede/duply.net