Menu
▾
▴
[Bacula-bugs] [bacula 0000990]: Database password for catalog backups out in the open
|
From: <bac...@li...> - 2007-10-23 00:32:52
|
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-22-2007 20:32 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 <mat...@st...> 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 matthijs@stdio:~$ 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). 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 ====================================================================== |
