Skip to content

bugzilla
bugzilla
Commit 43ff85bc authored by jake%bugzilla.org's avatar jake%bugzilla.org
Browse files
Options

Correct some minor typos in the security chapter.

parent 0b1945b0
Show whitespace changes
Inline Side-by-side
Showing with 61 additions and 39 deletions
docs/en/xml/security.xml
View file @ 43ff85bc
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
<!-- $Id: security.xml,v 1.16 2008/04/04 06:48:23 lpsolit%gmail.com Exp $ -->
<!-- $Id: security.xml,v 1.2 2008/04/04 06:48:09 jake%bugzilla.org Exp $ -->
<chapter id="security">
<title>Bugzilla Security</title>
......@@ -49,8 +49,8 @@
<quote>SYSTEM</quote> introduces obvious security concerns, the
problems introduced by running everything as <quote>nobody</quote> may
not be so obvious. Basically, if you run every daemon as
<quote>nobody</quote> and one of them gets compromised it can
compromise every other daemon running as <quote>nobody</quote> on your
<quote>nobody</quote> and one of them gets comprimised it can
comprimise every other daemon running as <quote>nobody</quote> on your
machine. For this reason, it is recommended that you create a user
account for each daemon.
</para>
......@@ -68,10 +68,9 @@
<section id="security-os-chroot">
<title>The <filename>chroot</filename> Jail</title>
<para>
If your system supports it, you may wish to consider running
<para>If your system supports it, you may wish to consider running
Bugzilla inside of a <filename>chroot</filename> jail. This option
provides unprecedented security by restricting anything running
provides unpresidented security by restricting anything running
inside the jail from accessing any information outside of it. If you
wish to use this option, please consult the documentation that came
with your system.
......@@ -90,7 +89,7 @@
<title>The MySQL System Account</title>
<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
for instructions.
</para>
......@@ -141,21 +140,28 @@
have no other reason to access MySQL remotely, then you should disable
the network access. This, along with the suggestion in
<xref linkend="security-os-ports"/>, will help protect your system from
any remote vulnerabilities in MySQL.
any remote vulnerabilites in MySQL. This is done using different
methods in MySQL versions 3 and 4.
</para>
<example id="security-mysql-network-ex">
<title>Disabling Networking in MySQL</title>
<example>
<title>Disabling Networking in MySQL 3.x</title>
<para>Simply enter the following in <filename>/etc/my.cnf</filename>:
<para>Simply enter the following in <filename>/etc/my.conf</filename>:
<screen>
[mysqld]
[myslqd]
# Prevent network access to MySQL.
skip-networking
</screen>
</para>
</example>
<example>
<title>Disabling Networking in MySQL 4.x</title>
<para>There's a bug in Bugzilla about this</para>
</example>
</section>
......@@ -171,19 +177,20 @@ skip-networking
<section id="security-webserver">
<title>Web server</title>
<title>Webserver</title>
<section id="security-webserver-access">
<title>Disabling Remote Access to Bugzilla Configuration Files</title>
<para>
There are many files that are placed in the Bugzilla directory
area that should not be accessible from the web. Because of the way
<para>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 quick way is to run
<filename>testserver.pl</filename> to check if your web server serves
Bugzilla files as expected. If not, you may want to follow the few
steps below.
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 a directory outside
the webroot. See
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=44659">bug 44659</ulink>
for more information.
</para>
<tip>
......@@ -203,6 +210,15 @@ skip-networking
<simplelist type="inline">
<member><filename>*.pl</filename></member>
<member><filename>*localconfig*</filename></member>
<member><filename>runtests.sh</filename></member>
</simplelist>
</para>
</listitem>
<listitem>
<para>But allow:
<simplelist type="inline">
<member><filename>localconfig.js</filename></member>
<member><filename>localconfig.rdf</filename></member>
</simplelist>
</para>
</listitem>
......@@ -292,19 +308,23 @@ skip-networking
</itemizedlist>
<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
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>
or
<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>
<tip>
<para>Be sure to check <xref linkend="http"/> for instructions
specific to the web server you use.
specific to the webserver you use.
</para>
</tip>
......@@ -347,25 +367,27 @@ skip-networking
<section id="security-bugzilla-charset">
<title>Prevent users injecting malicious Javascript</title>
<para>If you installed Bugzilla version 2.22 or later from scratch,
then the <emphasis>utf8</emphasis> parameter is switched on by default.
This makes Bugzilla explicitly set the character encoding, following
<para>It is possible for a Bugzilla user to take advantage of character
set encoding ambiguities to inject HTML into Bugzilla comments. This
could include malicious scripts.
Due to internationalization concerns, we are unable to
incorporate by default the code changes suggested by
<ulink
url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">a
CERT advisory</ulink> recommending exactly this.
The following therefore does not apply to you; just keep
<emphasis>utf8</emphasis> turned on.
url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">the
CERT advisory</ulink> on this issue.
If your installation is for an English speaking audience only, making the
change in <xref linkend="security-bugzilla-charset-ex"/> will prevent
this problem.
</para>
<para>If you've upgraded from an older version, then it may be possible
for a Bugzilla user to take advantage of character set encoding
ambiguities to inject HTML into Bugzilla comments.
This could include malicious scripts.
This is because due to internationalization concerns, we are unable to
turn the <emphasis>utf8</emphasis> parameter on by default for upgraded
installations.
Turning it on manually will prevent this problem.
<example id="security-bugzilla-charset-ex">
<para>Locate the following line in
<filename>Bugzilla/CGI.pm</filename>:
<programlisting>$self->charset('');</programlisting>
and change it to:
<programlisting>$self->charset('ISO-8859-1');</programlisting>
</para>
</example>
</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