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. -