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 ++++++++++++++++++++++++++++--------------
1 file changed, 243 insertions(+), 125 deletions(-)
(limited to 'docs/sgml/administration.sgml')
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.
+
+
+
+
-
-
-