Commit 7ac9720e authored by zach%zachlipton.com's avatar zach%zachlipton.com

Finish up fix for bug 22472 ("runtests.sh: die, die, die!"). Remove

references to runtests.sh in docs, checksetup.pl, and other fine places. r=LpSolit, a=my snapple peach iced tea
parent 123a2f2d
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> --> <!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
<!-- $Id: installation.xml,v 1.94 2008/04/04 06:47:24 mozilla%colinogilvie.co.uk Exp $ --> <!-- $Id: installation.xml,v 1.95 2008/04/04 06:47:25 zach%zachlipton.com Exp $ -->
<chapter id="installing-bugzilla"> <chapter id="installing-bugzilla">
<title>Installing Bugzilla</title> <title>Installing Bugzilla</title>
...@@ -1008,7 +1008,6 @@ c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s ...@@ -1008,7 +1008,6 @@ c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
ns_register_filter preauth GET /bugzilla/*.pl filter_deny ns_register_filter preauth GET /bugzilla/*.pl filter_deny
ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
ns_register_filter preauth GET /bugzilla/data/* filter_deny ns_register_filter preauth GET /bugzilla/data/* filter_deny
ns_register_filter preauth GET /bugzilla/template/* filter_deny ns_register_filter preauth GET /bugzilla/template/* filter_deny
......
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> --> <!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
<!-- $Id: security.xml,v 1.1 2008/04/03 19:05:43 lpsolit%gmail.com Exp $ --> <!-- $Id: security.xml,v 1.6 2008/04/04 06:48:13 zach%zachlipton.com Exp $ -->
<chapter id="security"> <chapter id="security">
<title>Bugzilla Security</title> <title>Bugzilla Security</title>
...@@ -49,15 +49,15 @@ ...@@ -49,15 +49,15 @@
<quote>SYSTEM</quote> introduces obvious security concerns, the <quote>SYSTEM</quote> introduces obvious security concerns, the
problems introduced by running everything as <quote>nobody</quote> may problems introduced by running everything as <quote>nobody</quote> may
not be so obvious. Basically, if you run every daemon as not be so obvious. Basically, if you run every daemon as
<quote>nobody</quote> and one of them gets compromised it can <quote>nobody</quote> and one of them gets comprimised it can
compromise every other daemon running as <quote>nobody</quote> on your comprimise every other daemon running as <quote>nobody</quote> on your
machine. For this reason, it is recommended that you create a user machine. For this reason, it is recommended that you create a user
account for each daemon. account for each daemon.
</para> </para>
<note> <note>
<para>You will need to set the <option>webservergroup</option> option <para>You will need to set the <option>webservergroup</option> option
in <filename>localconfig</filename> to the group your web server runs in <filename>localconfig</filename> to the group your webserver runs
as. This will allow <filename>./checksetup.pl</filename> to set file as. This will allow <filename>./checksetup.pl</filename> to set file
permissions on Unix systems so that nothing is world-writable. permissions on Unix systems so that nothing is world-writable.
</para> </para>
...@@ -90,7 +90,7 @@ ...@@ -90,7 +90,7 @@
<title>The MySQL System Account</title> <title>The MySQL System Account</title>
<para>As mentioned in <xref linkend="security-os-accounts"/>, the MySQL <para>As mentioned in <xref linkend="security-os-accounts"/>, the MySQL
daemon should run as a non-privileged, unique user. Be sure to consult daemon should run as a non-privleged, unique user. Be sure to consult
the MySQL documentation or the documentation that came with your system the MySQL documentation or the documentation that came with your system
for instructions. for instructions.
</para> </para>
...@@ -137,19 +137,19 @@ ...@@ -137,19 +137,19 @@
<section id="security-mysql-network"> <section id="security-mysql-network">
<title>Network Access</title> <title>Network Access</title>
<para>If MySQL and your web server both run on the same machine and you <para>If MySQL and your webserver both run on the same machine and you
have no other reason to access MySQL remotely, then you should disable have no other reason to access MySQL remotely, then you should disable
the network access. This, along with the suggestion in the network access. This, along with the suggestion in
<xref linkend="security-os-ports"/>, will help protect your system from <xref linkend="security-os-ports"/>, will help protect your system from
any remote vulnerabilities in MySQL. any remote vulnerabilites in MySQL.
</para> </para>
<example id="security-mysql-network-ex"> <example id="security-mysql-network-ex">
<title>Disabling Networking in MySQL</title> <title>Disabling Networking in MySQL</title>
<para>Simply enter the following in <filename>/etc/my.cnf</filename>: <para>Simply enter the following in <filename>/etc/my.conf</filename>:
<screen> <screen>
[mysqld] [myslqd]
# Prevent network access to MySQL. # Prevent network access to MySQL.
skip-networking skip-networking
</screen> </screen>
...@@ -171,19 +171,20 @@ skip-networking ...@@ -171,19 +171,20 @@ skip-networking
<section id="security-webserver"> <section id="security-webserver">
<title>Web server</title> <title>Webserver</title>
<section id="security-webserver-access"> <section id="security-webserver-access">
<title>Disabling Remote Access to Bugzilla Configuration Files</title> <title>Disabling Remote Access to Bugzilla Configuration Files</title>
<para> <para>There are many files that are placed in the Bugzilla directory
There are many files that are placed in the Bugzilla directory area that should not be accessable from the web. Because of the way
area that should not be accessible from the web server. Because of the way
Bugzilla is currently layed out, the list of what should and should not Bugzilla is currently layed out, the list of what should and should not
be accessible is rather complicated. A quick way is to run be accessible is rather complicated. A new installation method is
<filename>testserver.pl</filename> to check if your web server serves currently in the works which should solve this by allowing files that
Bugzilla files as expected. If not, you may want to follow the few shouldn't be accessible from the web to be placed in a directory outside
steps below. the webroot. See
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=44659">bug 44659</ulink>
for more information.
</para> </para>
<tip> <tip>
...@@ -206,6 +207,14 @@ skip-networking ...@@ -206,6 +207,14 @@ skip-networking
</simplelist> </simplelist>
</para> </para>
</listitem> </listitem>
<listitem>
<para>But allow:
<simplelist type="inline">
<member><filename>localconfig.js</filename></member>
<member><filename>localconfig.rdf</filename></member>
</simplelist>
</para>
</listitem>
</itemizedlist> </itemizedlist>
</listitem> </listitem>
...@@ -292,25 +301,56 @@ skip-networking ...@@ -292,25 +301,56 @@ skip-networking
</itemizedlist> </itemizedlist>
<para>Be sure to test that data that should not be accessed remotely is <para>Be sure to test that data that should not be accessed remotely is
properly blocked. Of particular interest is the localconfig file which properly blocked. Of particular intrest is the localconfig file which
contains your database password. Also, be aware that many editors contains your database password. Also, be aware that many editors
create temporary and backup files in the working directory and that create temporary and backup files in the working directory and that
those should also not be accessible. For more information, see those should also not be accessable. For more information, see
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=186383">bug 186383</ulink> <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=186383">bug 186383</ulink>
or or
<ulink url="http://online.securityfocus.com/bid/6501">Bugtraq ID 6501</ulink>. <ulink url="http://online.securityfocus.com/bid/6501">Bugtraq ID 6501</ulink>.
To test, simply run <filename>testserver.pl</filename>, as said above. To test, simply point your web browser at the file; for example, to
test mozilla.org's installation, we'd try to access
<ulink url="http://bugzilla.mozilla.org/localconfig"/>. You should get
a <quote><errorcode>403</errorcode> <errorname>Forbidden</errorname></quote>
error.
</para> </para>
<tip> <tip>
<para>Be sure to check <xref linkend="http"/> for instructions <para>Be sure to check <xref linkend="http"/> for instructions
specific to the web server you use. specific to the webserver you use.
</para> </para>
</tip> </tip>
</section> </section>
<section id="security-webserver-mod-throttle">
<title>Using <filename>mod_throttle</filename> to Prevent a DOS</title>
<note>
<para>This section only applies to people who have chosen the Apache
webserver. It may be possible to do similar things with other
webservers. Consult the documentation that came with your webserver
to find out.
</para>
</note>
<para>It is possible for a user, by mistake or on purpose, to access
the database many times in a row which can result in very slow access
speeds for other users (effectively, a
<glossterm linkend="gloss-dos">DOS</glossterm> attack). If your
Bugzilla installation is experiencing this problem, you may install
the Apache module <filename>mod_throttle</filename> which can limit
connections by IP address. You may download this module at
<ulink url="http://www.snert.com/Software/mod_throttle/"/>.
Follow the instructions to install into your Apache install.
The command you need is
<command>ThrottleClientIP</command>. See the
<ulink url="http://www.snert.com/Software/mod_throttle/">documentation</ulink>
for more information.</para>
</section>
</section> </section>
...@@ -320,25 +360,28 @@ skip-networking ...@@ -320,25 +360,28 @@ skip-networking
<section id="security-bugzilla-charset"> <section id="security-bugzilla-charset">
<title>Prevent users injecting malicious Javascript</title> <title>Prevent users injecting malicious Javascript</title>
<para>If you installed Bugzilla version 2.22 or later from scratch, <para>It is possible for a Bugzilla user to take advantage of character
then the <emphasis>utf8</emphasis> parameter is switched on by default. set encoding ambiguities to inject HTML into Bugzilla comments. This
This makes Bugzilla explicitly set the character encoding, following could include malicious scripts.
Due to internationalization concerns, we are unable to
incorporate by default the code changes suggested by
<ulink <ulink
url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">a url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">the
CERT advisory</ulink> recommending exactly this. CERT advisory</ulink> on this issue.
The following therefore does not apply to you; just keep Making the change in <xref linkend="security-bugzilla-charset-ex"/> will
<emphasis>utf8</emphasis> turned on. prevent this problem.
</para> </para>
<para>If you've upgraded from an older version, then it may be possible <example id="security-bugzilla-charset-ex">
for a Bugzilla user to take advantage of character set encoding <title>Forcing Bugzilla to output a charset</title>
ambiguities to inject HTML into Bugzilla comments.
This could include malicious scripts. <para>Locate the following line in
This is because due to internationalization concerns, we are unable to <filename>Bugzilla/CGI.pm</filename>:
turn the <emphasis>utf8</emphasis> parameter on by default for upgraded <programlisting>$self->charset('');</programlisting>
installations. and change it to:
Turning it on manually will prevent this problem. <programlisting>$self->charset('UTF-8');</programlisting>
</para> </para>
</example>
</section> </section>
</section> </section>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment