From 36a23d81d3d62a69dd5f2f6d0cade001d59aac6b Mon Sep 17 00:00:00 2001
From: "jake%bugzilla.org" <>
Date: Sun, 16 Feb 2003 01:22:41 +0000
Subject: Bug 191537 - Improvements to the security section.
---
docs/sgml/administration.sgml | 368 ++++++++++++++++++++++++++++--------------
docs/sgml/glossary.sgml | 40 +++--
docs/sgml/installation.sgml | 250 +---------------------------
docs/xml/administration.xml | 368 ++++++++++++++++++++++++++++--------------
docs/xml/glossary.xml | 40 +++--
docs/xml/installation.xml | 250 +---------------------------
6 files changed, 560 insertions(+), 756 deletions(-)
(limited to 'docs')
diff --git a/docs/sgml/administration.sgml b/docs/sgml/administration.sgml
index 3cd55a616..f04e2b5ce 100644
--- a/docs/sgml/administration.sgml
+++ b/docs/sgml/administration.sgml
@@ -764,155 +764,273 @@
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
+ of these directions, please submit a bug to &bzg-bugs;.
- To secure your installation:
-
-
-
-
- There is no substitute for understanding the tools on your
- system!
+
+ 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.
+
+
- Read
-
- The MySQL Privilege System
- until you can recite it from memory!
-
+
+ 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.
+
+
-
- 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.
-
+
+ MySQL
-
- Do not run Apache as
- nobody
+ 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.
+
- . 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
+
+
+ Consult the documentation that came with your system for
+ information on making mysqld run as an
+ unprivleged user.
+
+
- is a real user on UNIX systems. Having a process run as user id
- nobody
+
+ 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.
+
+
- 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.
-
-
-
+
+ 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
+
+
-
- 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.
-
+
+ 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.
+
+
- 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.
+
+ 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.
+
- 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
+
+ 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.
+
- ). 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.
-
+
+
+ In the main Bugzilla directory, you should:
+
+
+ Block:
+
+ *.pl
+ *localconfig*
+ runtests.sh
+
+
+
+
+ But allow:
+
+ localconfig.js
+ localconfig.rdf
+
+
+
+
+
-
- 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!
+
+ In data:
+
+
+ Block everything
+
+
+ But allow:
+
+ duplicates.rdf
+
+
+
+
+
- . This means that anyone who can get access to your system can do
- whatever they want to your Bugzilla installation.
+
+ 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
+
+
+
+
+
-
- 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.
-
+
+ In Bugzilla:
+
+
+ Block everything
+
+
+
- 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.
+
+ In template:
+
+
+ Block everything
+
+
+
+
+
+
+ Bugzilla ships with the ability to generate
+ .htaccess files instructing
+ Apache which files
+ should and should not be accessible. For more information, see
+ .
+
- FIX ME BEFORE RELEASE!!!!!
- 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.
+ 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
+ . You should
+ get a 403 Forbidden
+ error.
+
+
+
+ Not following the instructions in this section, including
+ testing, may result in sensitive information being globally
+ accessible.
+
+
+
+
+ You should check to see if instructions
+ have been included for your web server. You should also compare those
+ instructions with this list to make sure everything is properly
+ accounted for.
+
+
+
+
-
-
-
diff --git a/docs/sgml/glossary.sgml b/docs/sgml/glossary.sgml
index 191b3fb39..15b7fe948 100644
--- a/docs/sgml/glossary.sgml
+++ b/docs/sgml/glossary.sgml
@@ -242,17 +242,24 @@
-
- mysqld
+
+ MySQL
- mysqld is the name of the
- daemon
-
- for the MySQL database. In general, it is invoked automatically
- through the use of the System V init scripts on GNU/Linux and
- AT&T System V-based systems, such as Solaris and HP/UX, or
- through the RC scripts on BSD-based systems.
+ MySQL is currently the required
+ RDBMS for Bugzilla. MySQL
+ can be downloaded from . While you
+ should familiarize yourself with all of the documentation, some high
+ points are:
+
+
+
+ MySQL
+ Privilege System - Much more detailed information about
+ the suggestions in .
+
+
+
@@ -311,6 +318,21 @@
+
+ R
+
+
+ Relational DataBase Managment System
+ RDBMS
+
+
+ A relational database management system is a database system
+ that stores information in tables that are related to each other.
+
+
+
+
+
S
diff --git a/docs/sgml/installation.sgml b/docs/sgml/installation.sgml
index 286706126..da32ad5f9 100644
--- a/docs/sgml/installation.sgml
+++ b/docs/sgml/installation.sgml
@@ -763,152 +763,6 @@ perl -pi -e 's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm s
-
- 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:
-
-
- 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 ;-)
-
-
-
-
-
Configuring Bugzilla
@@ -1160,85 +1014,6 @@ bash# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; chars
-
-
- <filename>.htaccess</filename>
- files and security
-
- To enhance the security of your Bugzilla installation, Bugzilla's
- checksetup.pl script will generate
-
- .htaccess
-
-
- files which the Apache webserver can use to restrict access to the
- bugzilla data files.
- These .htaccess files will not work with Apache 1.2.x - but this
- has security holes, so you shouldn't be using it anyway.
-
- If you are using an alternate provider of
- webdot
-
- services for graphing (as described when viewing
- editparams.cgi
-
- in your web browser), you will need to change the ip address in
- data/webdot/.htaccess
-
- to the ip address of the webdot server that you are using.
-
-
-
- The default .htaccess file may not provide adequate access
- restrictions, depending on your web server configuration. Be sure to
- check the <Directory> entries for your Bugzilla directory so that
- the
- .htaccess
-
- file is allowed to override web server defaults. For instance, let's
- assume your installation of Bugzilla is installed to
- /usr/local/bugzilla
-
- . You should have this <Directory> entry in your
- httpd.conf
-
- file:
-
-
-
-
- Options +FollowSymLinks +Indexes +Includes +ExecCGI
- AllowOverride All
-
-]]>
-
-
-
- The important part above is
- AllowOverride All
-
- . Without that, the
- .htaccess
-
- file created by
- checksetup.pl
-
- will not have sufficient permissions to protect your Bugzilla
- installation.
-
- If you are using Internet Information Server (IIS) or another
- web server which does not observe
- .htaccess
- conventions, you can disable their creation by editing
- localconfig
- and setting the
- $create_htaccess
- variable to
- 0.
-
-
-
@@ -1358,11 +1133,11 @@ C:\perl> <command>ppm <module name></command>
</para>
</note>
- <note>
+ <tip>
<para>A complete list of modules that can be installed using ppm can
be found at <ulink url="http://www.activestate.com/PPMPackages/5.6plus">http://www.activestate.com/PPMPackages/5.6plus</ulink>.
</para>
- </note>
+ </tip>
</section>
<section id="win32-code-changes">
@@ -1400,19 +1175,6 @@ my $webservergid = '8'
</programlisting>
</section>
- <section id="win32-code-mail">
- <title>Making mail work
-
- The easiest way to get mail working is to use the mail patches
- on bug
- 124174. With any luck, this patch will receive the required
- reviews and integrated into the main Bugzilla distribution very soon.
- Until that happens, there's at least one report of this patch working
- well on Windows.
-
-
-
-
System Calls
@@ -1459,7 +1221,7 @@ system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filena
As is the case on Unix based systems, any web server should be
able to handle Bugzilla; however, the Bugzilla Team still recommends
Apache whenever asked. No matter what web server you choose, be sure
- to pay attention to the security notes in .
+ to pay attention to the security notes in .
More information on configuring specific web servers can be found in
.
@@ -1480,7 +1242,7 @@ system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filena
<productname>Mac OS X</productname>
-
+
There are a lot of common libraries and utilities out there that
Apple did not include with Mac OS X, but which run perfectly well on it.
The GD library, which Bugzilla needs to do bug graphs, is one of
@@ -1559,7 +1321,7 @@ system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filena
that can be configured to run CGI scripts
should be able to handle Bugzilla. No matter what web server you choose, but
especially if you choose something other than Apache, you should be sure to read
- .
+ .
The plan for this section is to eventually document the specifics of how to lock
@@ -1696,7 +1458,7 @@ deny from all
Also, and this can't be stressed enough, make sure that files such as
localconfig and your data
- directory are secured as described in .
+ directory are secured as described in .
diff --git a/docs/xml/administration.xml b/docs/xml/administration.xml
index 3cd55a616..f04e2b5ce 100644
--- a/docs/xml/administration.xml
+++ b/docs/xml/administration.xml
@@ -764,155 +764,273 @@
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
+ of these directions, please submit a bug to &bzg-bugs;.
- To secure your installation:
-
-
-
-
- There is no substitute for understanding the tools on your
- system!
+
+ 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.
+
+
- Read
-
- The MySQL Privilege System
- until you can recite it from memory!
-
+
+ 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.
+
+
-
- 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.
-
+
+ MySQL
-
- Do not run Apache as
- nobody
+ 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.
+
- . 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
+
+
+ Consult the documentation that came with your system for
+ information on making mysqld run as an
+ unprivleged user.
+
+
- is a real user on UNIX systems. Having a process run as user id
- nobody
+
+ 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.
+
+
- 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.
-
-
-
+
+ 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
+
+
-
- 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.
-
+
+ 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.
+
+
- 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.
+
+ 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.
+
- 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
+
+ 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.
+
- ). 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.
-
+
+
+ In the main Bugzilla directory, you should:
+
+
+ Block:
+
+ *.pl
+ *localconfig*
+ runtests.sh
+
+
+
+
+ But allow:
+
+ localconfig.js
+ localconfig.rdf
+
+
+
+
+
-
- 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!
+
+ In data:
+
+
+ Block everything
+
+
+ But allow:
+
+ duplicates.rdf
+
+
+
+
+
- . This means that anyone who can get access to your system can do
- whatever they want to your Bugzilla installation.
+
+ 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
+
+
+
+
+
-
- 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.
-
+
+ In Bugzilla:
+
+
+ Block everything
+
+
+
- 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.
+
+ In template:
+
+
+ Block everything
+
+
+
+
+
+
+ Bugzilla ships with the ability to generate
+ .htaccess files instructing
+ Apache which files
+ should and should not be accessible. For more information, see
+ .
+
- FIX ME BEFORE RELEASE!!!!!
- 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.
+ 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
+ . You should
+ get a 403 Forbidden
+ error.
+
+
+
+ Not following the instructions in this section, including
+ testing, may result in sensitive information being globally
+ accessible.
+
+
+
+
+ You should check to see if instructions
+ have been included for your web server. You should also compare those
+ instructions with this list to make sure everything is properly
+ accounted for.
+
+
+
+
-
-
-
diff --git a/docs/xml/glossary.xml b/docs/xml/glossary.xml
index 191b3fb39..15b7fe948 100644
--- a/docs/xml/glossary.xml
+++ b/docs/xml/glossary.xml
@@ -242,17 +242,24 @@
-
- mysqld
+
+ MySQL
- mysqld is the name of the
- daemon
-
- for the MySQL database. In general, it is invoked automatically
- through the use of the System V init scripts on GNU/Linux and
- AT&T System V-based systems, such as Solaris and HP/UX, or
- through the RC scripts on BSD-based systems.
+ MySQL is currently the required
+ RDBMS for Bugzilla. MySQL
+ can be downloaded from . While you
+ should familiarize yourself with all of the documentation, some high
+ points are:
+
+
+
+ MySQL
+ Privilege System - Much more detailed information about
+ the suggestions in .
+
+
+
@@ -311,6 +318,21 @@
+
+ R
+
+
+ Relational DataBase Managment System
+ RDBMS
+
+
+ A relational database management system is a database system
+ that stores information in tables that are related to each other.
+
+
+
+
+
S
diff --git a/docs/xml/installation.xml b/docs/xml/installation.xml
index 286706126..da32ad5f9 100644
--- a/docs/xml/installation.xml
+++ b/docs/xml/installation.xml
@@ -763,152 +763,6 @@ perl -pi -e 's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm s
-
- 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:
-
-
- 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 ;-)
-
-
-
-
-
Configuring Bugzilla
@@ -1160,85 +1014,6 @@ bash# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; chars
-
-
- <filename>.htaccess</filename>
- files and security
-
- To enhance the security of your Bugzilla installation, Bugzilla's
- checksetup.pl script will generate
-
- .htaccess
-
-
- files which the Apache webserver can use to restrict access to the
- bugzilla data files.
- These .htaccess files will not work with Apache 1.2.x - but this
- has security holes, so you shouldn't be using it anyway.
-
- If you are using an alternate provider of
- webdot
-
- services for graphing (as described when viewing
- editparams.cgi
-
- in your web browser), you will need to change the ip address in
- data/webdot/.htaccess
-
- to the ip address of the webdot server that you are using.
-
-
-
- The default .htaccess file may not provide adequate access
- restrictions, depending on your web server configuration. Be sure to
- check the <Directory> entries for your Bugzilla directory so that
- the
- .htaccess
-
- file is allowed to override web server defaults. For instance, let's
- assume your installation of Bugzilla is installed to
- /usr/local/bugzilla
-
- . You should have this <Directory> entry in your
- httpd.conf
-
- file:
-
-
-
-
- Options +FollowSymLinks +Indexes +Includes +ExecCGI
- AllowOverride All
-
-]]>
-
-
-
- The important part above is
- AllowOverride All
-
- . Without that, the
- .htaccess
-
- file created by
- checksetup.pl
-
- will not have sufficient permissions to protect your Bugzilla
- installation.
-
- If you are using Internet Information Server (IIS) or another
- web server which does not observe
- .htaccess
- conventions, you can disable their creation by editing
- localconfig
- and setting the
- $create_htaccess
- variable to
- 0.
-
-
-
@@ -1358,11 +1133,11 @@ C:\perl> <command>ppm <module name></command>
</para>
</note>
- <note>
+ <tip>
<para>A complete list of modules that can be installed using ppm can
be found at <ulink url="http://www.activestate.com/PPMPackages/5.6plus">http://www.activestate.com/PPMPackages/5.6plus</ulink>.
</para>
- </note>
+ </tip>
</section>
<section id="win32-code-changes">
@@ -1400,19 +1175,6 @@ my $webservergid = '8'
</programlisting>
</section>
- <section id="win32-code-mail">
- <title>Making mail work
-
- The easiest way to get mail working is to use the mail patches
- on bug
- 124174. With any luck, this patch will receive the required
- reviews and integrated into the main Bugzilla distribution very soon.
- Until that happens, there's at least one report of this patch working
- well on Windows.
-
-
-
-
System Calls
@@ -1459,7 +1221,7 @@ system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filena
As is the case on Unix based systems, any web server should be
able to handle Bugzilla; however, the Bugzilla Team still recommends
Apache whenever asked. No matter what web server you choose, be sure
- to pay attention to the security notes in .
+ to pay attention to the security notes in .
More information on configuring specific web servers can be found in
.
@@ -1480,7 +1242,7 @@ system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filena
<productname>Mac OS X</productname>
-
+
There are a lot of common libraries and utilities out there that
Apple did not include with Mac OS X, but which run perfectly well on it.
The GD library, which Bugzilla needs to do bug graphs, is one of
@@ -1559,7 +1321,7 @@ system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filena
that can be configured to run CGI scripts
should be able to handle Bugzilla. No matter what web server you choose, but
especially if you choose something other than Apache, you should be sure to read
- .
+ .
The plan for this section is to eventually document the specifics of how to lock
@@ -1696,7 +1458,7 @@ deny from all
Also, and this can't be stressed enough, make sure that files such as
localconfig and your data
- directory are secured as described in .
+ directory are secured as described in .
--
cgit v1.2.3-24-g4f1b