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, please submit a bug to Bugzilla.

This is not meant to be a comprehensive list of every possible
security issue regarding the tools mentioned in this section. There is
no subsitute for reading the information written by the authors of any
software running on your system.

5.6.1. TCP/IP Ports

TCP/IP defines 65,000 some ports for trafic. Of those, Bugzilla
only needs 1... 2 if you need to use features that require e-mail such
as bug moving or the e-mail interface from contrib. You should audit
your server and make sure that you aren't listening on any ports you
don't need to be. You may also wish to use some kind of firewall
software to be sure that trafic can only be recieved on ports you
specify.

5.6.2. MySQL

MySQL ships by default with many settings that should be changed.
By defaults it allows anybody to connect from localhost without a
password and have full administrative capabilities. It also defaults to
not have a root password (this is not the same as
the system root). Also, many installations default to running
mysqld as the system root.

Make sure you are running at least version 3.22.32 of MySQL
as earlier versions had notable security holes.

Consult the documentation that came with your system for
information on making mysqld run as an
unprivleged user.

You should also be sure to disable the anonymous user account
and set a password for the root user. This is accomplished using the
following commands:

From this point forward you will need to use
mysql -u root -p and enter
new_password when prompted when using the
mysql client.

If you run MySQL on the same machine as your httpd server, you
should consider disabling networking from within MySQL by adding
the following to your /etc/my.conf:

[myslqd]
# Prevent network access to MySQL.
skip-networking

You may also consider running MySQL, or even all of Bugzilla
in a chroot jail; however, instructions for doing that are beyond
the scope of this document.

5.6.3. Daemon Accounts

Many daemons, such as Apache's httpd and MySQL's mysqld default to
running as either "root" or "nobody". Running
as "root" introduces obvious security problems, but the
problems introduced by running everything as "nobody" may
not be so obvious. Basically, if you're running every daemon as
"nobody" and one of them gets comprimised, they all get
comprimised. For this reason it is recommended that you create a user
account for each daemon.

You will need to set the webservergroup to
the group you created for your webserver to run as in
localconfig. This will allow
./checksetup.pl to better adjust the file
permissions on your Bugzilla install so as to not require making
anything world-writable.

5.6.4. Web Server Access Controls

There are many files that are placed in the Bugzilla directory
area that should not be accessable from the web. Because of the way
Bugzilla is currently layed out, the list of what should and should
not be accessible is rather complicated. A new installation method
is currently in the works which should solve this by allowing files
that shouldn't be accessible from the web to be placed in directory
outside the webroot. See
bug
44659 for more information.

In the main Bugzilla directory, you should:

Block:
*.pl, *localconfig*, runtests.sh, processmail, syncshadowdb

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

Bugzilla ships with the ability to generate
.htaccess files instructing Apache which files
should and should not be accessible.

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 403Forbidden
error.

Not following the instructions in this section, including
testing, may result in sensitive information being globally
accessible.