From 9bf6fdb3d2bab8133c641dc097dd5c2c9f5d5090 Mon Sep 17 00:00:00 2001
From: "bbaetz%acm.org" <>
Date: Fri, 4 Apr 2008 11:47:18 +0000
Subject: Bug 180635 - Enhance Bugzilla::User to store additional information
r=myk,jake
---
docs/en/xml/administration.xml | 426 +++++++++++++++++++++++------------------
1 file changed, 242 insertions(+), 184 deletions(-)
(limited to 'docs/en')
diff --git a/docs/en/xml/administration.xml b/docs/en/xml/administration.xml
index 05d693aff..ecf465fdc 100644
--- a/docs/en/xml/administration.xml
+++ b/docs/en/xml/administration.xml
@@ -618,7 +618,7 @@
Maximum Votes a person can put on a single
- bug":
+ bug:
It should probably be some number lower than the
"Maximum votes per person". Don't set this field to "0" if
"Maximum votes per person" is non-zero; that doesn't make
@@ -764,215 +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
+
+
+
+
- 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.
-
- $BUGZILLA_HOME/.htaccess
-
- deny from all
-
-
- allow from all
-
- ]]>
+
+ Bugzilla ships with the ability to generate
+ .htaccess files instructing
+ Apache which files
+ should and should not be accessible. For more information, see
+ .
+
- $BUGZILLA_HOME/data/.htaccess
-
- allow from all
-
- ]]>
+ 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.
+
- $BUGZILLA_HOME/data/webdot
-
- Allow from 192.20.225.10
- Deny from all
-
-
-# Allow access by a local copy of 'dot' to .png, .gif, .jpg, and
-# .map files
-
- Allow from all
-
-
-# And no directory listings, either.
-Deny from all
- ]]>
+
+ 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.
+
- $BUGZILLA_HOME/Bugzilla/.htaccess
-
-# nothing in this directory is retrievable unless overriden by an .htaccess
-# in a subdirectory
-deny from all
-
-
-
- $BUGZILLA_HOME/template/.htaccess
-
-# nothing in this directory is retrievable unless overriden by an .htaccess
-# in a subdirectory
-deny from all
-
-
+
-
-
-
@@ -1327,7 +1385,7 @@ deny from all
positive check, which returns 1 (allow) if certain conditions are true,
or a negative check, which returns 0 (deny.) E.g.:
if ($field eq "qacontact") {
- if (UserInGroup("quality_assurance")) {
+ if (Bugzilla->user->groups("quality_assurance")) {
return 1;
}
else {
@@ -1337,7 +1395,7 @@ deny from all
This says that only users in the group "quality_assurance" can change
the QA Contact field of a bug. Getting more weird:
if (($field eq "priority") &&
- ($vars->{'user'}{'login'} =~ /.*\@example\.com$/))
+ (Bugzilla->user->email =~ /.*\@example\.com$/))
{
if ($oldvalue eq "P1") {
return 1;
@@ -1574,7 +1632,7 @@ sgml-local-ecat-files:nil
sgml-minimize-attributes:nil
sgml-namecase-general:t
sgml-omittag:t
-sgml-parent-document:("Bugzilla-Guide.sgml" "book" "chapter")
+sgml-parent-document:("Bugzilla-Guide.xml" "book" "chapter")
sgml-shorttag:t
sgml-tag-region-if-active:t
End:
--
cgit v1.2.3-24-g4f1b