5.6. Bugzilla Security
 | Poorly-configured MySQL and Bugzilla installations have given attackers full access to systems in the past. Please take these guidelines seriously, even for Bugzilla machines hidden away behind your firewall. 80% of all computer trespassers are insiders, not anonymous crackers. |
 | These instructions must, of necessity, be somewhat vague since Bugzilla runs on so many different platforms. If you have refinements of these directions for specific platforms, please submit them to mozilla-webtools@mozilla.org |
To secure your installation:
There is no substitute for understanding the tools on your system! Read The MySQL Privilege System until you can recite it from memory!
Lock down /etc/inetd.conf. Heck, disable inet entirely on this box. It should only listen to port 25 for Sendmail and port 80 for Apache.
Do not run Apache as "nobody" . This will require very lax permissions in your Bugzilla directories. Run it, instead, as a user with a name, set via your httpd.conf file.
"nobody" is a real user on UNIX systems. Having a process run as user id "nobody" is absolutely no protection against system crackers versus using any other user account. As a general security measure, I recommend you create unique user ID's for each daemon running on your system and, if possible, use "chroot" to jail that process away from the rest of your system.
Ensure you have adequate access controls for the $BUGZILLA_HOME/data/ directory, as well as the $BUGZILLA_HOME/localconfig file. The localconfig file stores your "bugs" database account password. In addition, some files under $BUGZILLA_HOME/data/ store sensitive information.
Also, beware that some text editors create backup files in the current working directory so you need to also secure files like localconfig~.
Simply blocking .*localconfig.* won't work because the QuickSearch feature requires the web browser to be able to retrieve localconfig.js and others may be introduced in the future (see bug 186383 for more information.
Bugzilla provides default .htaccess files to protect the most common Apache installations. However, you should verify these are adequate according to the site-wide security policy of your web server, and ensure that the .htaccess files are allowed to "override" default permissions set in your Apache configuration files. Covering Apache security is beyond the scope of this Guide; please consult the Apache documentation for details.
If you are using a web server that does not support the .htaccess control method, you are at risk! After installing, check to see if you can view the file localconfig in your web browser (e.g.: http://bugzilla.mozilla.org/localconfig ). If you can read the contents of this file, your web server has not secured your bugzilla directory properly and you must fix this problem before deploying Bugzilla. If, however, it gives you a "Forbidden" error, then it probably respects the .htaccess conventions and you are good to go.
When you run checksetup.pl, the script will attempt to modify various permissions on files which Bugzilla uses. If you do not have a webservergroup set in the localconfig file, then Bugzilla will have to make certain files world readable and/or writable. THIS IS INSECURE! . This means that anyone who can get access to your system can do whatever they want to your Bugzilla installation.
This also means that if your webserver runs all cgi scripts as the same user/group, anyone on the system who can run cgi scripts will be able to take control of your Bugzilla installation.
On Apache, you can use .htaccess files to protect access to these directories, as outlined in Bugs 57161 and 186383 for the localconfig file, and Bug 65572 for adequate protection in your data/ directory. Also, don't forget about the template/ and Bugzilla/ directories and to allow access to the data/webdot directory for the 192.20.225.10 IP address if you are using webdot from research.att.com. The easiest way to accomplish this is to set $create_htaccess to 1 in localconfig. However, the information below is provided for those that want to know exactly what is created.
Note the instructions which follow are Apache-specific. If you use IIS, Netscape, or other non-Apache web servers, please consult your system documentation for how to secure these files from being transmitted to curious users.
$BUGZILLA_HOME/.htaccess
# don't allow people to retrieve non-cgi executable files or our private data <FilesMatch ^(.*\.pl|.*localconfig.*|processmail|runtests.sh)$> deny from all </FilesMatch> <FilesMatch ^(localconfig.js|localconfig.rdf)$> allow from all </FilesMatch>$BUGZILLA_HOME/data/.htaccess
# nothing in this directory is retrievable unless overriden by an .htaccess # in a subdirectory; the only exception is duplicates.rdf, which is used by # duplicates.xul and must be loadable over the web deny from all <Files duplicates.rdf> allow from all </Files>$BUGZILLA_HOME/data/webdot
# Restrict access to .dot files to the public webdot server at research.att.com # if research.att.com ever changed their IP, or if you use a different # webdot server, you'll need to edit this <FilesMatch ^[0-9]+\.dot$> Allow from 192.20.225.10 Deny from all </FilesMatch> # Allow access by a local copy of 'dot' to .png, .gif, .jpg, and # .map files <FilesMatch ^[0-9]+\.(png|gif|jpg|map)$> Allow from all </FilesMatch> # And no directory listings, either. Deny from all$BUGZILLA_HOME/Bugzilla/.htaccess
# nothing in this directory is retrievable unless overriden by an .htaccess # in a subdirectory deny from all$BUGZILLA_HOME/template/.htaccess
# nothing in this directory is retrievable unless overriden by an .htaccess # in a subdirectory deny from all