From: jake%bugzilla.org <>
Date: Sun, 16 Feb 2003 05:46:25 +0000 (+0000)
Subject: Port security section rewrite from bug 191537 to the 2.16 docs.
X-Git-Tag: bugzilla-2.16.3~28
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=84773ed9cdd18c47234933100db18a7d0899e8aa;p=thirdparty%2Fbugzilla.git
Port security section rewrite from bug 191537 to the 2.16 docs.
---
diff --git a/docs/sgml/administration.sgml b/docs/sgml/administration.sgml
index fa5e0e445b..f7d2e8e34f 100644
--- a/docs/sgml/administration.sgml
+++ b/docs/sgml/administration.sgml
@@ -748,7 +748,6 @@
-
Bugzilla Security
@@ -763,140 +762,271 @@
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:
-
-
-
- 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.
+
+
-
-
- There is no substitute for understanding the tools on your
- system!
+
+ 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.
+
+
- Read
-
- The MySQL Privilege System
- until you can recite it from memory!
-
+
+ MySQL
-
- 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 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.
+
-
- Do not run Apache as
- nobody
+
+
+ Make sure you are running at least version 3.22.32 of MySQL
+ as earlier versions had notable security holes.
+
+
- . 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.
+
+
+
+
+
+
+
+
+ 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.
+
- 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.
+
-
- 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.
-
+
+ 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.
+
- On Apache, you can use .htaccess files to protect access to
- these directories, as outlined in
- Bug
- 57161
+
+
+ In the main Bugzilla directory, you should:
+
+
+ Block:
+
+ *.pl
+ *localconfig*
+ runtests.sh
+ processmail
+ syncshadowdb
+
+
+
+
+ But allow:
+
+ localconfig.js
+ localconfig.rdf
+
+
+
+
+
- for the localconfig file, and
- Bug
- 65572
+
+ In data:
+
+
+ Block everything
+
+
+ But allow:
+
+ duplicates.rdf
+
+
+
+
+
- for adequate protection in your data/ directory.
+
+ 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
+
+
+
+
+
- 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.
+
+ In Bugzilla:
+
+
+ Block everything
+
+
+
- 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
+
+ In template:
+
+
+ Block everything
+
+
+
+
+
+
+ Bugzilla ships with the ability to generate
+ .htaccess files instructing Apache which files
+ should and should not be accessible.
+
+
+ You should test to make sure that the files mentioned above are
+ not accessible from the Internet, especially your
+ localconfig file which contains your database
+ password. To test, simply point your web browser at the file; for
+ example, to test mozilla.org's installation, we'd try to access
+ . You should
+ get a 403 Forbidden
+ error.
+
- 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.
+
+
+
-
-
-
diff --git a/docs/sgml/installation.sgml b/docs/sgml/installation.sgml
index 6931e3e4e6..1ebe0bcb1d 100644
--- a/docs/sgml/installation.sgml
+++ b/docs/sgml/installation.sgml
@@ -765,152 +765,6 @@ AllowOverride Limit
-
- 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
@@ -1956,7 +1810,7 @@ binmode(STDOUT);
not necessary
for Bugzilla 2.13 and later, which includes the current release,
- Bugzilla &bz-ver;.
+ Bugzilla &bz-ver;.
Removing encrypt() for Windows NT Bugzilla version 2.12 or
earlier
diff --git a/docs/xml/administration.xml b/docs/xml/administration.xml
index fa5e0e445b..f7d2e8e34f 100644
--- a/docs/xml/administration.xml
+++ b/docs/xml/administration.xml
@@ -748,7 +748,6 @@
-
Bugzilla Security
@@ -763,140 +762,271 @@
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:
-
-
-
- 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.
+
+
-
-
- There is no substitute for understanding the tools on your
- system!
+
+ 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.
+
+
- Read
-
- The MySQL Privilege System
- until you can recite it from memory!
-
+
+ MySQL
-
- 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 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.
+
-
- Do not run Apache as
- nobody
+
+
+ Make sure you are running at least version 3.22.32 of MySQL
+ as earlier versions had notable security holes.
+
+
- . 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.
+
+
+
+
+
+
+
+
+ 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.
+
- 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.
+
-
- 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.
-
+
+ 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.
+
- On Apache, you can use .htaccess files to protect access to
- these directories, as outlined in
- Bug
- 57161
+
+
+ In the main Bugzilla directory, you should:
+
+
+ Block:
+
+ *.pl
+ *localconfig*
+ runtests.sh
+ processmail
+ syncshadowdb
+
+
+
+
+ But allow:
+
+ localconfig.js
+ localconfig.rdf
+
+
+
+
+
- for the localconfig file, and
- Bug
- 65572
+
+ In data:
+
+
+ Block everything
+
+
+ But allow:
+
+ duplicates.rdf
+
+
+
+
+
- for adequate protection in your data/ directory.
+
+ 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
+
+
+
+
+
- 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.
+
+ In Bugzilla:
+
+
+ Block everything
+
+
+
- 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
+
+ In template:
+
+
+ Block everything
+
+
+
+
+
+
+ Bugzilla ships with the ability to generate
+ .htaccess files instructing Apache which files
+ should and should not be accessible.
+
+
+ You should test to make sure that the files mentioned above are
+ not accessible from the Internet, especially your
+ localconfig file which contains your database
+ password. To test, simply point your web browser at the file; for
+ example, to test mozilla.org's installation, we'd try to access
+ . You should
+ get a 403 Forbidden
+ error.
+
- 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.
+
+
+
-
-
-
diff --git a/docs/xml/installation.xml b/docs/xml/installation.xml
index 6931e3e4e6..1ebe0bcb1d 100644
--- a/docs/xml/installation.xml
+++ b/docs/xml/installation.xml
@@ -765,152 +765,6 @@ AllowOverride Limit
-
- 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
@@ -1956,7 +1810,7 @@ binmode(STDOUT);
not necessary
for Bugzilla 2.13 and later, which includes the current release,
- Bugzilla &bz-ver;.
+ Bugzilla &bz-ver;.
Removing encrypt() for Windows NT Bugzilla version 2.12 or
earlier