--- Begin Message ---
A NOTE has been added to this issue.
======================================================================
http://bugs.bacula.org/view.php?id=990
======================================================================
Reported By: jgoerzen
Assigned To:
======================================================================
Project: bacula
Issue ID: 990
Category: Director
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
======================================================================
Date Submitted: 10-18-2007 12:25 EDT
Last Modified: 10-19-2007 13:23 EDT
======================================================================
Summary: Database password for catalog backups out in the
open
Description:
This report received at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809
From: Matthijs Kooijman <[EMAIL PROTECTED]>
Hi,
the default bacula configuration file supports backing up the catalog
database using the "make_catalog_backup" script. For this, the following
line is in bacula-dir.conf:
RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula"
If the database is password protected, the password must be added as a
third argument. This works as expected, but poses up a number of
security risks.
Firstly, when the backup fails, the complete command line is put into an
email with the error messages, including the password. For example:
15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command
"/etc/bacula/scripts/make_catalog_backup bacula bacula
c1130ee16f7125579d6214bcd114b71"
15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error:
1045: Access denied for user 'bacula'@'localhost' (using password:
YES) when trying to +connect
Since email is no secure channel, this can expose the database password.
Having the database password in the error message hardly serves any
purpose and should probably be avoided.
Additionally, having the password on the commandline, makes it available
to users on the same machine. The command lines of running processes are
usually accessible to users, so running a simple
[EMAIL PROTECTED]:~$ ps aux|grep catalog
bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh
/etc/bacula/scripts/make_catalog_backup bacula bacula
0c1130ee16f7125579d6214bcd114b71
reveals the database password.
It would be better to store the password in an external file, and pass
that filename to the make_catalog_backup script. In this way, the
make_catalog_backup script is still generic, but the database password
is not exposed (though that file should be readable by the bacula user,
not only by root).
The attached patch achieves the above, while maintaining backwards
compatibility. It might be better to remove backwards compatibility to
prevent users from using the old, insecure way, however. Additionally,
my modifications to the script could pose problems if someone uses a
database password that is also the name of an existing file.
Gr.
Matthijs
======================================================================
----------------------------------------------------------------------
kern - 10-19-07 08:29
----------------------------------------------------------------------
Yes, I think this is a good idea, but it is a bit too kludgie for me.
Instead, what do you think of the idea of having argument 3 be a path to
where the password is stored, and it would be in a file named
pw-<database-name>.
So the my proposed code would test for the existence of the file using:
if [ -r "$3/pw-$1" ]; then
MYSQLPASSWORD=" --password=`cat \"$3/pw-$1\"`"
...
The above would reduce the risk of finding a random file. Probably a
simpler proposal would be to ignore argument 3 altogether -- i.e.:
if [ -r "pw-$1" ]; then
MYSQLPASSWORD=" --password=`cat \"pw-$1\"`"
As you mention, the backward compatibility is not very desireable, but not
having it would create a *lot* of support problems and possibly some
serious errors if the user overlooked fixing it and didn't notice that his
catalog backups were failing.
----------------------------------------------------------------------
jgoerzen - 10-19-07 10:52
----------------------------------------------------------------------
Hi Kern,
Thanks for your comments on these bugs. I have forwarded your note to
Matthijs, who submitted this to DEbian. I'll forward any response back to
you.
----------------------------------------------------------------------
COUSINM - 10-19-07 13:23
----------------------------------------------------------------------
There is be the possibility of using MYSQL_PWD environment variable, just
the same as the script does for postgresql.
But mysql's documentation says this :
Store your password in the MYSQL_PWD environment variable. This method of
specifying your MySQL password must be considered extremely insecure and
should not be used. Some versions of ps include an option to display the
environment of running processes. If you set MYSQL_PWD, your password is
exposed to any other user who runs ps. Even on systems without such a
version of ps, it is unwise to assume that there are no other methods by
which users can examine process environments. See Section 2.4.20,
“Environment Variables”.
What this paragraph says is applicable for both engines : if the
environment variables can be displayed by ps on some systems, it's
dangerous. Linux doesn't do that as far as I know, but I don't know for
other unixes.
The other possibility I see is using configuration files :
For mysql, in .my.cnf (in user's home directory)
[client]
password=your_pass
(http://dev.mysql.com/doc/refman/5.0/en/password-security.html)
For postgresql, in .pgpass (in user's home directory)
hostname:port:database:username:password
(http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html)
With this solution, you get rid of the configuration parameter, but the
user has some additionnal setup to do.
Issue History
Date Modified Username Field Change
======================================================================
10-18-07 12:25 jgoerzen New Issue
10-18-07 12:25 jgoerzen File Added: bacula_passwd.diff
10-19-07 08:29 kern Note Added: 0002886
10-19-07 08:29 kern Status new => feedback
10-19-07 10:52 jgoerzen Note Added: 0002887
10-19-07 13:23 COUSINM Note Added: 0002888
======================================================================
--- End Message ---
