From: jake%bugzilla.org <> Date: Sun, 16 Feb 2003 23:41:03 +0000 (+0000) Subject: Recompile docs for the 2.16.3 release X-Git-Tag: bugzilla-2.16.3~26 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7ef170fb48580f573ed3165941acce4955773031;p=thirdparty%2Fbugzilla.git Recompile docs for the 2.16.3 release --- diff --git a/docs/html/Bugzilla-Guide.html b/docs/html/Bugzilla-Guide.html index 7a715361e7..9f78b6aac0 100644 --- a/docs/html/Bugzilla-Guide.html +++ b/docs/html/Bugzilla-Guide.html @@ -1,7 +1,7 @@
2003-02-16
mysqld defaults to running as root |
it defaults to allowing external network connections |
it has a known port number, and is easy to detect |
it defaults to no passwords whatsoever |
it defaults to allowing "File_Priv" |
This means anyone from anywhere on the internet can not only drop - the database with one SQL command, and they can write as root to the - system.
To see your permissions do: -
bash# - - mysql -u root -p - - |
mysql> - - use mysql; - - |
mysql> - - show tables; - - |
mysql> - - select * from user; - - |
mysql> - - select * from db; - - |
To fix the gaping holes: -
DELETE FROM user WHERE User=''; |
UPDATE user SET Password=PASSWORD('new_password') WHERE - user='root'; |
FLUSH PRIVILEGES; |
If you're not running "mit-pthreads" you can use: -
GRANT USAGE ON *.* TO bugs@localhost; |
GRANT ALL ON bugs.* TO bugs@localhost; |
REVOKE DROP ON bugs.* FROM bugs@localhost; |
FLUSH PRIVILEGES; |
With "mit-pthreads" you'll need to modify the "globals.pl" - Mysql->Connect line to specify a specific host name instead of - "localhost", and accept external connections: -
GRANT USAGE ON *.* TO bugs@bounce.hop.com; |
GRANT ALL ON bugs.* TO bugs@bounce.hop.com; |
REVOKE DROP ON bugs.* FROM bugs@bounce.hop.com; |
FLUSH PRIVILEGES; |
Consider also: -
Turning off external networking with "--skip-networking", - unless you have "mit-pthreads", in which case you can't. Without - networking, MySQL connects with a Unix domain socket.
using the --user= option to mysqld to run it as an - unprivileged user.
running MySQL in a chroot jail
running the httpd in a chroot jail
making sure the MySQL passwords are different from the OS - passwords (MySQL "root" has nothing to do with system - "root").
running MySQL on a separate untrusted machine
making backups ;-)
You should run through the parameters on the Edit Parameters page (link in the footer) and set them all to appropriate values. @@ -4362,7 +4087,7 @@ CLASS="section" >
for Bugzilla 2.13 and later, which includes the current release, - Bugzilla &bz-ver;. + Bugzilla 2.16.3.
4.5.1. Bundle::Bugzilla makes me upgrade to Perl 5.6.1
4.5.2. DBD::Sponge::db prepare failed
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 +>Bugzilla.
To secure your installation: - -
Ensure you are running at least MysQL version 3.22.32 or newer. - Earlier versions had notable security holes and (from a security - point of view) poor default configuration choices. 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. + |
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. +
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. +
There is no substitute for understanding the tools on your - system! - - Read - The MySQL Privilege System - until you can recite it from memory!
Make sure you are running at least version 3.22.32 of MySQL + as earlier versions had notable security holes. +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.
Consult the documentation that came with your system for + information on making mysqld run as an + unprivleged user. +Do not run Apache as - 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: +
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 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. +
Many daemons, such as Apache's httpd and MySQL's mysqld default to + running as either "root" or "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.
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. +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 -
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. -
But allow: + localconfig.js, localconfig.rdf +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.
In data:If you are using a web server that does not support the - .htaccess control method, - you are at risk!
Block everything
But allow: + duplicates.rdf - - After installing, check to see if you can view the file - "localconfig" in your web browser (e.g.: - http://bugzilla.mozilla.org/localconfig
In data/webdot:
If you use a remote webdot server:
Block everything
But allow + *.dot - - ). 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!Otherwise, if you use a local GraphViz:
Block everything
But allow: + *.png, *.gif, *.jpg, *.map - - . This means that anyone who can get access to your system can do - whatever they want to your Bugzilla installation.
And if you don't use any dot:
Block everything
In Bugzilla:
Block everything
In template:
Block everything
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. Bugzilla ships with the ability to generate + .htaccess files instructing Apache which files + should and should not be accessible. + |
On Apache, you can use .htaccess files to protect access to - these directories, as outlined in - Bug - 57161 - - for the localconfig file, and - 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 + Bug - 65572http://bugzilla.mozilla.org/localconfig. You should + get a 403 Forbidden - - for adequate protection in your data/ directory.
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.
Place the following text into a file named ".htaccess", - readable by your web server, in your $BUGZILLA_HOME/data directory. -
<Files comments> allow from all </Files>
- deny from all
Place the following text into a file named ".htaccess", - readable by your web server, in your $BUGZILLA_HOME/ directory. - <Files localconfig> deny from all </Files> |
Microsoft has some advice on this matter, as well:
B.2.1. Bugzilla Database Basics
B.2.1.1. Bugzilla Database Tables
0-9, high ascii
The Bugzilla Guide The Bugzilla Guide - 2.16.3 ReleaseThe Bugzilla Guide The Bugzilla Guide - 2.16.3 ReleaseThe Bugzilla Guide The Bugzilla Guide - 2.16.3 ReleaseBugzilla Security
- 5.6.1. TCP/IP Ports
- 5.6.2. MySQL
- 5.6.3. Daemon Accounts
- 5.6.4. Web Server Access Controls
- 5.7.
- 5.7.1. What to Edit
- 5.7.2. How To Edit Templates
- 5.7.3. Template Formats
- 5.7.4. Particular Templates
The Bugzilla Guide The Bugzilla Guide - 2.16.3 ReleaseThe Bugzilla Guide The Bugzilla Guide - 2.16.3 Release1.1. Copyright Information
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. +
To secure your installation: - -
Ensure you are running at least MysQL version 3.22.32 or newer. - Earlier versions had notable security holes and (from a security - point of view) poor default configuration choices.
Make sure you are running at least version 3.22.32 of MySQL + as earlier versions had notable security holes. +There is no substitute for understanding the tools on your - system! - - Read - The MySQL Privilege System - until you can recite it from memory!
Consult the documentation that came with your system for + information on making mysqld run as an + unprivleged user. +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.
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: +
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 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 +Do not run Apache as - 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" - - . 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. -
. 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. +"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.
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. +
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 -
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. -
But allow: + localconfig.js, localconfig.rdf +In data:
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!
Block everything
But allow: + duplicates.rdf - - After installing, check to see if you can view the file - "localconfig" in your web browser (e.g.: - http://bugzilla.mozilla.org/localconfig
In data/webdot:
If you use a remote webdot server:
Block everything
But allow + *.dot - - ). 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!
Otherwise, if you use a local GraphViz:
Block everything
But allow: + *.png, *.gif, *.jpg, *.map - - . This means that anyone who can get access to your system can do - whatever they want to your Bugzilla installation.
And if you don't use any dot:
Block everything
In Bugzilla:
Block everything
In template:
Block everything
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. Bugzilla ships with the ability to generate + .htaccess files instructing Apache which files + should and should not be accessible. + |
On Apache, you can use .htaccess files to protect access to - these directories, as outlined in - Bug - 57161 - - for the localconfig file, and - 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 + Bug - 65572 - - for adequate protection in your data/ directory.
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.
Place the following text into a file named ".htaccess", - readable by your web server, in your $BUGZILLA_HOME/data directory. -
<Files comments> allow from all </Files>
- deny from all
Place the following text into a file named ".htaccess", - readable by your web server, in your $BUGZILLA_HOME/ directory. -
<Files localconfig> deny from all </Files>
- allow from all
Not following the instructions in this section, including + testing, may result in sensitive information being globally + accessible. - |
If you followed the installation instructions for setting up your - "bugs" and "root" user in MySQL, much of this should not apply to you. - If you are upgrading an existing installation of Bugzilla, you should - pay close attention to this section.
Most MySQL installs have "interesting" default security - parameters: -
mysqld defaults to running as root |
it defaults to allowing external network connections |
it has a known port number, and is easy to detect |
it defaults to no passwords whatsoever |
it defaults to allowing "File_Priv" |
This means anyone from anywhere on the internet can not only drop - the database with one SQL command, and they can write as root to the - system.
To see your permissions do: -
bash# - - mysql -u root -p - - |
mysql> - - use mysql; - - |
mysql> - - show tables; - - |
mysql> - - select * from user; - - |
mysql> - - select * from db; - - |
To fix the gaping holes: -
DELETE FROM user WHERE User=''; |
UPDATE user SET Password=PASSWORD('new_password') WHERE - user='root'; |
FLUSH PRIVILEGES; |
If you're not running "mit-pthreads" you can use: -
GRANT USAGE ON *.* TO bugs@localhost; |
GRANT ALL ON bugs.* TO bugs@localhost; |
REVOKE DROP ON bugs.* FROM bugs@localhost; |
FLUSH PRIVILEGES; |
With "mit-pthreads" you'll need to modify the "globals.pl" - Mysql->Connect line to specify a specific host name instead of - "localhost", and accept external connections: -
GRANT USAGE ON *.* TO bugs@bounce.hop.com; |
GRANT ALL ON bugs.* TO bugs@bounce.hop.com; |
REVOKE DROP ON bugs.* FROM bugs@bounce.hop.com; |
FLUSH PRIVILEGES; |
Consider also: -
Turning off external networking with "--skip-networking", - unless you have "mit-pthreads", in which case you can't. Without - networking, MySQL connects with a Unix domain socket.
using the --user= option to mysqld to run it as an - unprivileged user.
running MySQL in a chroot jail
running the httpd in a chroot jail
making sure the MySQL passwords are different from the OS - passwords (MySQL "root" has nothing to do with system - "root").
running MySQL on a separate untrusted machine
making backups ;-)
You should run through the parameters on the Edit Parameters page (link in the footer) and set them all to appropriate values. diff --git a/docs/html/troubleshooting.html b/docs/html/troubleshooting.html index a772395cdf..1596027d67 100644 --- a/docs/html/troubleshooting.html +++ b/docs/html/troubleshooting.html @@ -7,7 +7,7 @@ NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ ">
for Bugzilla 2.13 and later, which includes the current release, - Bugzilla &bz-ver;. + Bugzilla 2.16.3.+ +# This script compiles all the documentation. + +use diagnostics; +use strict; + +use File::Basename; + +############################################################################### +# Environment Variable Checking +############################################################################### + +my ($JADE_PUB, $LDP_HOME); + +if (defined $ENV{JADE_PUB} && $ENV{JADE_PUB} ne '') { + $JADE_PUB = $ENV{JADE_PUB}; +} +else { + die "You need to set the JADE_PUB environment variable first."; +} + +if (defined $ENV{LDP_HOME} && $ENV{LDP_HOME} ne '') { + $LDP_HOME = $ENV{LDP_HOME}; +} +else { + die "You need to set the LDP_HOME environment variable first."; +} + +############################################################################### +# Subs +############################################################################### + +sub MakeDocs($$) { + + my ($name, $cmdline) = @_; + + print "Creating $name documentation ...\n"; + print "$cmdline\n\n"; + system $cmdline; + print "\n"; + +} + +############################################################################### +# Make the docs ... +############################################################################### + +chdir dirname($0); +chdir 'html'; + +MakeDocs('separate HTML', "jade -t sgml -i html -d $LDP_HOME/ldp.dsl\#html " . + "$JADE_PUB/xml.dcl ../sgml/Bugzilla-Guide.sgml"); +MakeDocs('big HTML', "jade -V nochunks -t sgml -i html -d " . + "$LDP_HOME/ldp.dsl\#html $JADE_PUB/xml.dcl " . + "../sgml/Bugzilla-Guide.sgml > Bugzilla-Guide.html"); +MakeDocs('big text', "lynx -dump -justify=off -nolist Bugzilla-Guide.html " . + "> ../txt/Bugzilla-Guide.txt"); diff --git a/docs/txt/Bugzilla-Guide.txt b/docs/txt/Bugzilla-Guide.txt index c715741c4c..84bd2c0689 100644 --- a/docs/txt/Bugzilla-Guide.txt +++ b/docs/txt/Bugzilla-Guide.txt @@ -1,10 +1,12 @@ -The Bugzilla Guide +The Bugzilla Guide - 2.16.3 Release Matthew P. Barnson The Bugzilla Team + 2003-02-16 + This is the documentation for Bugzilla, the mozilla.org bug-tracking system. Bugzilla is an enterprise-class piece of software that powers issue-tracking for hundreds of organizations around the world, @@ -509,7 +511,7 @@ How to use this License for your documents 1.3. New Versions - This is the 2.16 version of The Bugzilla Guide. It is so named to + This is the 2.16.3 version of The Bugzilla Guide. It is so named to match the current version of Bugzilla. If you are reading this from any source other than those below, please check one of these mirrors to make sure you are reading an up-to-date version of the Guide. @@ -1388,71 +1390,7 @@ perl -pi -e Bugzilla. _________________________________________________________________ -4.1.10. Securing MySQL - - If you followed the installation instructions for setting up your - "bugs" and "root" user in MySQL, much of this should not apply to you. - If you are upgrading an existing installation of Bugzilla, you should - pay close attention to this section. - - Most MySQL installs have "interesting" default security parameters: - - mysqld defaults to running as root - it defaults to allowing external network connections - it has a known port number, and is easy to detect - it defaults to no passwords whatsoever - it defaults to allowing "File_Priv" - - This means anyone from anywhere on the internet can not only drop the - database with one SQL command, and they can write as root to the - system. - - To see your permissions do: - - bash# mysql -u root -p - mysql> use mysql; - mysql> show tables; - mysql> select * from user; - mysql> select * from db; - - To fix the gaping holes: - - DELETE FROM user WHERE User=''; - UPDATE user SET Password=PASSWORD('new_password') WHERE user='root'; - FLUSH PRIVILEGES; - - If you're not running "mit-pthreads" you can use: - - GRANT USAGE ON *.* TO bugs@localhost; - GRANT ALL ON bugs.* TO bugs@localhost; - REVOKE DROP ON bugs.* FROM bugs@localhost; - FLUSH PRIVILEGES; - - With "mit-pthreads" you'll need to modify the "globals.pl" - Mysql->Connect line to specify a specific host name instead of - "localhost", and accept external connections: - - GRANT USAGE ON *.* TO bugs@bounce.hop.com; - GRANT ALL ON bugs.* TO bugs@bounce.hop.com; - REVOKE DROP ON bugs.* FROM bugs@bounce.hop.com; - FLUSH PRIVILEGES; - - Consider also: - - 1. Turning off external networking with "--skip-networking", unless - you have "mit-pthreads", in which case you can't. Without - networking, MySQL connects with a Unix domain socket. - 2. using the --user= option to mysqld to run it as an unprivileged - user. - 3. running MySQL in a chroot jail - 4. running the httpd in a chroot jail - 5. making sure the MySQL passwords are different from the OS - passwords (MySQL "root" has nothing to do with system "root"). - 6. running MySQL on a separate untrusted machine - 7. making backups ;-) - _________________________________________________________________ - -4.1.11. Configuring Bugzilla +4.1.10. Configuring Bugzilla You should run through the parameters on the Edit Parameters page (link in the footer) and set them all to appropriate values. They key @@ -1981,7 +1919,7 @@ rs\ScriptMap If attempting to run Bugzilla 2.12 or older, you will need to remove encrypt() calls from the Perl source. This is not necessary for Bugzilla 2.13 and later, which includes the current release, Bugzilla - &bz-ver;. + 2.16.3. Example 4-3. Removing encrypt() for Windows NT Bugzilla version 2.12 or earlier @@ -2531,81 +2469,129 @@ Chapter 5. Administering Bugzilla 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: - - 1. Ensure you are running at least MysQL version 3.22.32 or newer. - Earlier versions had notable security holes and (from a security - point of view) poor default configuration choices. - 2. There is no substitute for understanding the tools on your system! - Read The MySQL Privilege System until you can recite it from - memory! - 3. 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. - 4. 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. + of these directions, please submit a bug to Bugzilla. - Note + Warning + + 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 - "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. - 5. 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. - 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. + 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. + + 1. Make sure you are running at least version 3.22.32 of MySQL as + earlier versions had notable security holes. + 2. Consult the documentation that came with your system for + information on making mysqld run as an unprivleged user. + 3. 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: + +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 you will need to use mysql -u root -p and + enter new_password when prompted when using the mysql client. + 4. 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 + + + 5. 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. Note - 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 Bug 57161 for the localconfig file, - and Bug 65572 for adequate protection in your data/ directory. - 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. - Place the following text into a file named ".htaccess", readable - by your web server, in your $BUGZILLA_HOME/data directory. -
allow from all - deny from all - Place the following text into a file named ".htaccess", readable - by your web server, in your $BUGZILLA_HOME/ directory. -deny from all - allow from all + 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: + o Block everything + o But allow *.dot only for the remote webdot server + + Otherwise, if you use a local GraphViz: + o Block everything + o But allow: *.png, *.gif, *.jpg, *.map + + And if you don't use any dot: + o Block everything + * In Bugzilla: + + Block everything + * In template: + + Block everything + + Tip + + 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 403 Forbidden error. + + Caution + + Not following the instructions in this section, including testing, may + result in sensitive information being globally accessible. _________________________________________________________________ 5.7. Template Customisation