--- 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: closed
Resolution: not fixable
Fixed in Version:
======================================================================
Date Submitted: 10-18-2007 12:25 EDT
Last Modified: 10-23-2007 09:54 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.
----------------------------------------------------------------------
Dan Langille - 10-20-07 14:00
----------------------------------------------------------------------
Perhaps the best course of action is to highlight this as a security issue
in the Bacula documentation. Leave it to the user to decide what action to
take.
Each environment differs. If you are running your database server on a
system with non-trusted users, you need to take additional precautions
anyway.
Document it. Leave it.
----------------------------------------------------------------------
Dan Langille - 10-22-07 13:56
----------------------------------------------------------------------
See also http://secunia.com/advisories/27243/
----------------------------------------------------------------------
kern - 10-22-07 17:45
----------------------------------------------------------------------
I've though about it and decided to go with Dan's suggestion, that is
simply to add more documentation to the file indicating that passing the
password via the command line is insecure.
This is really a database dump implementation problem, or a sys admin
problem not really something that Bacula can solve (at least I don't have a
solution).
In addition, it doesn't seem to me that proposed solution will work, at
least not without additional quoting to delay the application of the ` and
'. If it does work, it would do so only for MySQL and not for PostgreSQL.
In other words, I find it a kludge and not a complete solution.
----------------------------------------------------------------------
Dan Langille - 10-22-07 18:10
----------------------------------------------------------------------
Kern: I'll document the issues on Tuesday. This is something I will enjoy
doing.
----------------------------------------------------------------------
Dan Langille - 10-22-07 19:55
----------------------------------------------------------------------
To date, these are the changes related to this issue:
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5779
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5780
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5782
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5783
----------------------------------------------------------------------
Dan Langille - 10-22-07 20:32
----------------------------------------------------------------------
A few things about this issue which are worth noting. In order for someone
to exploit this issue:
- first, the system would require untrusted users on the database server
- the sysadmin would have to use the default password and database name
(bacula, bacula), unlikely on a server with untrusted users
- if the sysadmin did change the default values, they would have to alter
the invocation of the script, would hopefully raise the issue then
Failing all this, we have added warnings to each place the script is used.
We have also added notes in several places in the documentation. I also
plan to send out an announcement to our users.
Note that in a default installation, the script is invoked with the
default user name and password (bacula, bacula).
----------------------------------------------------------------------
Dan Langille - 10-23-07 09:54
----------------------------------------------------------------------
Note: this issue has been documented since 2005:
http://www.bacula.org/rel-manual/Bacula_Security_Issues.html
"Be aware that if you are backing up your database using the default
script, if you have a password on your database, it will be passed as a
command line option to that script, and any user will be able to see this
information. If you want it to be secure, you will need to pass it by an
environment variable or a secure file."
Change log:
http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/docs/manual/security.tex?view=diff&r1=2701&r2=2702
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
10-20-07 02:34 COUSINM Issue Monitored: COUSINM
10-20-07 14:00 Dan Langille Note Added: 0002891
10-22-07 13:56 Dan Langille Note Added: 0002897
10-22-07 17:45 kern Note Added: 0002898
10-22-07 17:45 kern Status feedback => closed
10-22-07 17:45 kern Resolution open => not fixable
10-22-07 18:10 Dan Langille Note Added: 0002899
10-22-07 19:55 Dan Langille Note Added: 0002900
10-22-07 20:32 Dan Langille Note Added: 0002901
10-23-07 09:54 Dan Langille Note Added: 0002903
======================================================================
--- End Message ---
