The MySQL Privelege System</ULINK> until you can recite it from memory!</PARA>
<PARA>
At the very least, ensure you password the "mysql -u root" account and the "bugs" account, establish grant
table rights (consult the Keystone guide in Appendix C: The Bugzilla Database for some easy-to-use details)
that do not allow CREATE, DROP, RELOAD, SHUTDOWN, and PROCESS for user "bugs". I wrote up the Keystone
advice back when I knew far less about security than I do now : )
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>
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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Do not run Apache as "nobody". 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.</PARA>
</LISTITEM>
<LISTITEM>
<PARA>
Ensure you have adequate access controls for the $BUGZILLA_HOME/data/ and
$BUGZILLA_HOME/shadow/ directories, as well as the $BUGZILLA_HOME/localconfig file.
The localconfig file stores your "bugs" user password,
which would be terrible to have in the hands
of a criminal. Also some files under $BUGZILLA_HOME/data/ store sensitive information, and
$BUGZILLA_HOME/shadow/ stores bug information for faster retrieval. If you fail to secure
these directories and this file, you will expose bug information to those who may not
be allowed to see it.
</PARA>
<PARA>
On Apache, you can use .htaccess files to protect access to these directories, as outlined
in <ULINKURL="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug 57161</ULINK> for the
localconfig file, and <ULINKURL="http://bugzilla.mozilla.org/show_bug.cgi?id=65572">
Bug 65572</ULINK> for adequate protection in your data/ and shadow/ directories.
</PARA>
<PARA>
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.
</PARA>
<PARA>
Place the following text into a file named ".htaccess", readable by your web server,
in your $BUGZILLA_HOME/data directory.
<LITERALLAYOUT>
<Files comments>
allow from all
</Files>
deny from all
</LITERALLAYOUT>
</PARA>
<PARA>
Place the following text into a file named ".htaccess", readable by your web server,
in your $BUGZILLA_HOME/ directory.
<LITERALLAYOUT>
<Files localconfig>
deny from all
</Files>
allow from all
</LITERALLAYOUT>
</PARA>
<PARA>
Place the following text into a file named ".htaccess", readable by your web server,
in your $BUGZILLA_HOME/shadow directory.
<LITERALLAYOUT>
deny from all
</LITERALLAYOUT>
</PARA>
</LISTITEM>
</ORDEREDLIST>
</PARA>
</SECTION>
</CHAPTER>
We have 5 users, User1, User2, User3, User4, User5.
We have 8 bugs, Bug1, ..., Bug8.
Group membership is defined by this chart:
(X denotes that user is in that group.)
(I apologize for the nasty formatting of this table. Try viewing
it in a text-based browser or something for now. -MPB)
G G G G
r r r r
o o o o
u u u u
p p p p
1 2 3 4
+-+-+-+-+
User1|X| | | |
+-+-+-+-+
User2| |X| | |
+-+-+-+-+
User3|X| |X| |
+-+-+-+-+
User4|X|X|X| |
+-+-+-+-+
User5| | | | |
+-+-+-+-+
Bug restrictions are defined by this chart:
(X denotes that bug is restricted to that group.)
G G G G
r r r r
o o o o
u u u u
p p p p
1 2 3 4
+-+-+-+-+
Bug1| | | | |
+-+-+-+-+
Bug2| |X| | |
+-+-+-+-+
Bug3| | |X| |
+-+-+-+-+
Bug4| | | |X|
+-+-+-+-+
Bug5|X|X| | |
+-+-+-+-+
Bug6|X| |X| |
+-+-+-+-+
Bug7|X|X|X| |
+-+-+-+-+
Bug8|X|X|X|X|
+-+-+-+-+
Who can see each bug?
Bug1 has no group restrictions. Therefore, Bug1 can be seen by any
user, whatever their group membership. This is going to be the only
bug that User5 can see, because User5 isn't in any groups.
Bug2 can be seen by anyone in Group2, that is User2 and User4.
Bug3 can be seen by anyone in Group3, that is User3 and User4.
Bug4 can be seen by anyone in Group4. Nobody is in Group4, so none of
these users can see Bug4.
Bug5 can be seen by anyone who is in _both_ Group1 and Group2. This
is only User4. User1 cannot see it because he is not in Group2, and
User2 cannot see it because she is not in Group1.
Bug6 can be seen by anyone who is in both Group1 and Group3. This
would include User3 and User4. Similar to Bug5, User1 cannot see Bug6
because he is not in Group3.
Bug7 can be seen by anyone who is in Group1, Group2, and Group3. This
is only User4. All of the others are missing at least one of those
group privileges, and thus cannot see the bug.
Bug8 can be seen by anyone who is in Group1, Group2, Group3, and
Group4. There is nobody in all four of these groups, so nobody can
see Bug8. It doesn't matter that User4 is in Group1, Group2, and
Group3, since he isn't in Group4.
</literallayout>
</example>
</para>
</section>
</section>
<sectionid="security">
<title>Bugzilla Security</title>
<epigraph>
<para>
Putting your money in a wall safe is better protection than
depending on the fact that no one knows that you hide your
money in a mayonnaise jar in your fridge.
</para>
</epigraph>
<note>
<para>
Poorly-configured MySQL, Bugzilla, and FTP installations have
given attackers full access to systems in the past. Please
take these guidelines seriously, even for Bugzilla machines
hidden away behind your firewall. 80% of all computer
trespassers are insiders, not anonymous crackers.
</para>
</note>
<para>
Secure your installation.
<note>
<para>
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 <ulinkurl="mailto://mozilla-webtools@mozilla.org">mozilla-webtools@mozilla.org</ulink>
</para>
</note>
<orderedlist>
<listitem>
<para>
Ensure you are running at least MysQL version 3.22.32 or
newer. Earlier versions had notable security holes and
poorly secured default configuration choices.
</para>
</listitem>
<listitem>
<para><emphasis>There is no substitute for understanding the
tools on your system!</emphasis> Read <ulinkurl="http://www.mysql.com/documentation/mysql/bychapter/manual_Privilege_system.html"> The MySQL Privilege System</ulink> until you can recite it from memory!</para>
<para>
At the very least, ensure you password the "mysql -u root"
account and the "bugs" account, establish grant table
rights (consult the Keystone guide in Appendix C: The
Bugzilla Database for some easy-to-use details) that do
not allow CREATE, DROP, RELOAD, SHUTDOWN, and PROCESS for
user "bugs". I wrote up the Keystone advice back when I
knew far less about security than I do now : )
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Do not run Apache as <quote>nobody</quote>. 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.
<note>
<para>
<quote>nobody</quote> is a real user on UNIX systems.
Having a process run as user id <quote>nobody</quote>
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.
</para>
</note>
</para>
</listitem>
<listitem>
<para>
Ensure you have adequate access controls for the
$BUGZILLA_HOME/data/ and $BUGZILLA_HOME/shadow/
directories, as well as the $BUGZILLA_HOME/localconfig and
$BUGZILLA_HOME/globals.pl files. The localconfig file
stores your "bugs" user password, which would be terrible
to have in the hands of a criminal, while the "globals.pl"
stores some default information regarding your
installation which could aid a system cracker. In
addition, some files under $BUGZILLA_HOME/data/ store
sensitive information, and $BUGZILLA_HOME/shadow/ stores
bug information for faster retrieval. If you fail to
secure these directories and this file, you will expose
bug information to those who may not be allowed to see it.
</para>
<note>
<para>
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.
</para>
<para>
If you are using a web server that does not support the
.htaccess control method, <emphasis>you are at
risk!</emphasis> After installing, check to see if
you can view the file "localconfig" in your web browser
(e.g.: <ulinkurl="http://bugzilla.mozilla.org/localconfig"> http://bugzilla.mozilla.org/localconfig</ulink>). 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.
</para>
</note>
<para>
On Apache, you can use .htaccess files to protect access
to these directories, as outlined in <ulinkurl="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug 57161</ulink> for the localconfig file, and <ulinkurl="http://bugzilla.mozilla.org/show_bug.cgi?id=65572"> Bug 65572</ulink> for adequate protection in your data/ and shadow/ directories.
</para>
<para>
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.
</para>
<para>
Place the following text into a file named ".htaccess",
readable by your web server, in your $BUGZILLA_HOME/data
