2.2. Configuration
Poorly-configured MySQL and Bugzilla installations have + given attackers full access to systems in the past. Please take the + security parts of these guidelines seriously, even for Bugzilla + machines hidden away behind your firewall. |
2.2.1. localconfig
Once you run checksetup.pl with all the correct + modules installed, it displays a message about, and write out a + file called, + localconfig. This file contains the default + settings for a number of Bugzilla parameters. +
Load this file in your editor. The only value you + need to change is $db_pass, the password for + the user you will create for your database. + Pick a strong password (for simplicity, it should not contain + single quote characters) and put it here. +
The other options in the localconfig file + are documented by their accompanying comments. If you have a slightly + non-standard MySQL setup, you may wish to change one or more of + the other "$db_*" parameters. +
You may also wish to change the names of + the priorities, severities, operating systems and platforms for your + installation. However, you can always change these after installation + has finished; if you then re-run + checksetup.pl, the changes will get picked up. +
2.2.2. MySQL
2.2.2.1. Security
MySQL ships as insecure by default. + It allows anybody to on the local machine full administrative + capabilities without requiring a password; the special + MySQL root account (note: this is not the same as + the system root) also has no password. + Also, many installations default to running + mysqld as the system root. +
To disable the anonymous user account + and set a password for the root user, execute the following. The + root user password should be different to the bugs user password + you set in + localconfig in the previous section, + and also different to + the password for the system root account on your machine. +
bash$ mysql mysql + mysql> DELETE FROM user WHERE user = ''; + mysql> UPDATE user SET password = password('new_password') WHERE user = 'root'; + mysql> FLUSH PRIVILEGES;From this point forward, to run the + mysql command-line client, + you will need to type + mysql -u root -p and enter + new_password when prompted. +
If you run MySQL on the same machine as your web server, you + should disable remote access to MySQL by adding + the following to your /etc/my.conf: +
[myslqd] + # Prevent network access to MySQL. + skip-networking
Consult the documentation that came with your system for + information on making mysqld run as an + unprivileged user. +
For added security, you could also run MySQL, or even all + of Bugzilla + in a chroot jail; however, instructions for doing that are beyond + the scope of this document. +
2.2.2.2. Allow large attachments
You need to configure MySQL to accept large packets, if you + want to have attachments larger than 64K. Add the text + below to your + /etc/my.conf. + There is also a parameter in Bugzilla + for setting the maximum allowable attachment size, (default 1MB). + Bugzilla will only accept attachments up to the lower of these two + sizes. +
[mysqld] + # Allow packets up to 1M + set-variable = max_allowed_packet=1M |
2.2.2.3. Add a user to MySQL
You need to add a new MySQL user for + Bugzilla to use. (It's not safe to have Bugzilla use the MySQL root + account.) The following instructions assume the defaults in + localconfig; + if you changed those, you need to modify the + SQL command appropriately. You will need the + $db_pass password you set in + localconfig in + Section 2.2.1. +
We use an SQL GRANT command to create a + "bugs" + user. This also restricts the + "bugs" + user to operations within a database called + "bugs", and only allows the account to connect from + "localhost". + Modify it to reflect your setup if you will be connecting from + another machine or as a different user.
Run the mysql command-line client and + enter:
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE, + DROP,REFERENCES ON bugs.* TO bugs@localhost + IDENTIFIED BY '$db_pass'; + mysql> FLUSH PRIVILEGES |
If you are using MySQL 4, you need to add + the LOCK TABLES and + CREATE TEMPORARY TABLES permissions + to the list. + |
2.2.3. checksetup.pl
Next, rerun checksetup.pl. It reconfirms + that all the modules are present, and notices the altered + localconfig file, which it assumes you have edited to your + satisfaction. It compiles the UI templates, + connects to the database using the 'bugs' + user you created and the password you defined, and creates the + 'bugs' database and the tables therein. +
After that, it asks for details of an administrator account. Bugzilla + can have multiple administrators - you can create more later - but + it needs one to start off with. + Enter the email address of an administrator, his or her full name, + and a suitable Bugzilla password. +
checksetup.pl will then finish. You may rerun + checksetup.pl at any time if you wish. +
2.2.4. Web server
Configure your web server according to the instructions in the + appropriate section. The Bugzilla Team recommends Apache. +
2.2.4.1. Apache httpd
Load httpd.conf in your editor.
Uncomment (or add) the following line. + This configures Apache to run .cgi files outside the + cgi-bin directory. +
AddHandler cgi-script .cgi |
Apache uses <Directory> + directives to permit fine-grained permission setting. + Add the following two lines to a + <Directory> directive that + applies either to the Bugzilla directory or one of its parents + (e.g. the <Directory /var/www/html> + directive). + This allows Bugzilla's .htaccess files to + override global permissions, and allows .cgi files to run in the + Bugzilla directory. +
Options +ExecCGI +FollowSymLinks + AllowOverride Limit |
Add index.cgi to the end + of the DirectoryIndex + line.
checksetup.pl can set tighter permissions + on Bugzilla's files and directories if it knows what user the + webserver runs as. Look for the User + line in httpd.conf, and place that value in + the $webservergroup variable in + localconfig. Then rerun + checksetup.pl. +
2.2.4.2. Microsoft Internet Information Services
If you need, or for some reason even want, to use Microsoft's + Internet Information Services or + Personal Web Server you should be able + to. You will need to configure them to know how to run CGI scripts. + This is described in Microsoft Knowledge Base article + Q245225 + for Internet Information Services and + Q231998 + for Personal Web Server. +
Also, and this can't be stressed enough, make sure that files such as + localconfig and your data + directory are secured as described in Section 2.2.4.4. +
2.2.4.3. AOL Server
Ben FrantzDale reported success using AOL Server with Bugzilla. He + reported his experience and what appears below is based on that. +
AOL Server will have to be configured to run + CGI scripts, please consult + the documentation that came with your server for more information on + how to do this. +
Because AOL Server doesn't support .htaccess + files, you'll have to create a TCL + script. You should create an aolserver/modules/tcl/filter.tcl + file (the filename shouldn't matter) with the following contents (change + /bugzilla/ to the web-based path to + your Bugzilla installation): +
ns_register_filter preauth GET /bugzilla/localconfig filter_deny
+ ns_register_filter preauth GET /bugzilla/localconfig~ filter_deny
+ ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
+ ns_register_filter preauth GET /bugzilla/*.pl filter_deny
+ ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
+ ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
+ ns_register_filter preauth GET /bugzilla/data/* filter_deny
+ ns_register_filter preauth GET /bugzilla/template/* filter_deny
+
+ proc filter_deny { why } {
+ ns_log Notice "filter_deny"
+ return "filter_return"
+ }
+ |
This probably doesn't account for all possible editor backup + files so you may wish to add some additional variations of + localconfig. For more information, see + bug 186383 or Bugtraq ID 6501. + |
If you are using webdot from research.att.com (the default + configuration for the webdotbase paramater), you + will need to allow access to data/webdot/*.dot + for the reasearch.att.com machine. + If you are using a local installation of GraphViz, you will need to allow + everybody to access *.png, + *.gif, *.jpg, and + *.map in the + data/webdot directory. + |
2.2.4.4. Web Server Access Controls
Users of Apache can skip this section because + Bugzilla ships with .htaccess files which + restrict access in the manner required. + Users of other webservers, read on. +
There are several files in the Bugzilla directory + that should not be accessible from the web. You need to configure + your webserver so they they aren't. Not doing this may reveal + sensitive information such as database passwords. +
In the main Bugzilla directory, you should:
Block: + *.pl, *localconfig*, runtests.sh +
But allow: + localconfig.js, localconfig.rdf +
In data:
Block everything
But allow: + duplicates.rdf +
In data/webdot:
If you use a remote webdot server:
Block everything
But allow + *.dot + only for the remote webdot server
Otherwise, if you use a local GraphViz:
Block everything
But allow: + *.png, *.gif, *.jpg, *.map +
And if you don't use any dot:
Block everything
In Bugzilla:
Block everything
In template:
Block everything
You should test to make sure that the files mentioned above are + not accessible from the Internet, especially your + localconfig file which contains your database + password. To test, simply point your web browser at the file; for + example, to test mozilla.org's installation, we'd try to access + http://bugzilla.mozilla.org/localconfig. You should + get a 403 Forbidden + error. +
2.2.5. Bugzilla
Your Bugzilla should now be working. Access + http://<your-bugzilla-server>/ - + you should see the Bugzilla + front page. If not, consult the Troubleshooting section, + Section 2.5. +
Log in with the administrator account you defined in the last + checksetup.pl run. You should go through + the parameters on the Edit Parameters page + (see link in the footer) and see if there are any you wish to + change. + They key parameters are documented in Section 3.1; + you should certainly alter + maintainer and urlbase; + you may also want to alter + cookiepath or requirelogin. +
This would also be a good time to revisit the + localconfig file and make sure that the + names of the priorities, severities, platforms and operating systems + are those you wish to use when you start creating bugs. Remember + to rerun checksetup.pl if you change it. +
Bugzilla has several optional features which require extra + configuration. You can read about those in + Section 2.3. +