Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
bugzilla
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
etersoft
bugzilla
Commits
9bf6fdb3
Commit
9bf6fdb3
authored
Apr 04, 2008
by
bbaetz%acm.org
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Bug 180635 - Enhance Bugzilla::User to store additional information
r=myk,jake
parent
e996beda
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
232 additions
and
174 deletions
+232
-174
administration.xml
docs/en/xml/administration.xml
+232
-174
No files found.
docs/en/xml/administration.xml
View file @
9bf6fdb3
...
...
@@ -618,7 +618,7 @@
<listitem>
<para><emphasis>
Maximum Votes a person can put on a single
bug
"
</emphasis>
:
bug
</emphasis>
:
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 @@
<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
<ulink
url=
"mailto://mozilla-webtools@mozilla.org"
>
mozilla-webtools@mozilla.org
</ulink>
of these directions, please submit a bug to
&bzg-bugs;
.
</para>
</note>
<para>
To secure your installation:
<warning>
<para>
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.
</para>
</warning>
<section
id=
"security-networking"
>
<title>
TCP/IP Ports
</title>
<!-- TODO: Make this make sense (TCP/IP) -->
<para>
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.
</para>
</section>
<section
id=
"security-mysql"
>
<title>
MySQL
</title>
<para>
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
<emphasis>
not
</emphasis>
the same as
the system root). Also, many installations default to running
<application>
mysqld
</application>
as the system root.
</para>
<orderedlist>
<listitem>
<para>
<emphasis>
There is no substitute for understanding the tools on your
system!
</emphasis>
Read
<ulink
url=
"http://www.mysql.com/doc/P/r/Privilege_system.html"
>
The MySQL Privilege System
</ulink>
until you can recite it from memory!
</para>
<para>
Consult the documentation that came with your system for
information on making
<application>
mysqld
</application>
run as an
unprivleged user.
</para>
</listitem>
<listitem>
<para>
Lock down
<filename>
/etc/inetd.conf
</filename>
. Heck, disable
inet entirely on this box. It should only listen to port 25 for
Sendmail and port 80 for Apache.
</para>
<para>
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:
</para>
<programlisting>
<prompt>
bash$
</prompt>
mysql mysql
<prompt>
mysql
>
</prompt>
DELETE FROM user WHERE user = '';
<prompt>
mysql
>
</prompt>
UPDATE user SET password = password('
<replaceable>
new_password
</replaceable>
') WHERE user = 'root';
<prompt>
mysql
>
</prompt>
FLUSH PRIVILEGES;
</programlisting>
<para>
From this point forward you will need to use
<command>
mysql -u root -p
</command>
and enter
<replaceable>
new_password
</replaceable>
when prompted when using the
mysql client.
</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>
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
<filename>
/etc/my.conf
</filename>
:
</para>
<programlisting>
[myslqd]
# Prevent network access to MySQL.
skip-networking
</programlisting>
</listitem>
<listitem>
<para>
Ensure you have adequate access controls for the
<filename>
$BUGZILLA_HOME/data/
</filename>
directory, as well as the
<filename>
$BUGZILLA_HOME/localconfig
</filename>
file.
The localconfig file stores your "bugs" database account password.
In addition, some
files under
<filename>
$BUGZILLA_HOME/data/
</filename>
store sensitive
information.
<para>
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.
</para>
</listitem>
<para>
Also, beware that some text editors create backup files in the
current working directory so you need to also secure files like
<filename>
localconfig~
</filename>
.
</orderedlist>
</section>
<section
id=
"security-daemon"
>
<title>
Daemon Accounts
</title>
<para>
Many daemons, such as Apache's httpd and MySQL's mysqld default to
running as either
<quote>
root
</quote>
or
<quote>
nobody
</quote>
. Running
as
<quote>
root
</quote>
introduces obvious security problems, but the
problems introduced by running everything as
<quote>
nobody
</quote>
may
not be so obvious. Basically, if you're running every daemon as
<quote>
nobody
</quote>
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.
</para>
<note>
<para>
Simply blocking
<computeroutput>
.*localconfig.*
</computeroutput>
won't work because the QuickSearch feature requires the web browser
to be able to retrieve
<filename>
localconfig.js
</filename>
and
others may be introduced in the future (see
<ulink
url=
"http://bugzilla.mozilla.org/show_bug.cgi?id=186383"
>
bu
g
186383
</ulink>
for more information
.
<para>
You will need to set the
<varname>
webservergroup
</varname>
to
the group you created for your webserver to run as in
<filename>
localconfig
</filename>
. This will allow
<command>
./checksetup.pl
</command>
to better adjust the file
permissions on your Bugzilla install so as to not require makin
g
anything world-writable
.
</para>
</note>
<para>
Bugzilla provides default
<filename>
.htaccess
</filename>
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
<filename>
.htaccess
</filename>
files are allowed to
<quote>
override
</quote>
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.
</section>
<section
id=
"security-access"
>
<title>
Web Server Access Controls
</title>
<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 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
<ulink
url=
"http://bugzilla.mozilla.org/show_bug.cgi?id=44659"
>
bug 44659
</ulink>
for more information.
</para>
<para>
If you are using a web server that does not support the
<filename>
.htaccess
</filename>
control method,
<emphasis>
you are at risk!
</emphasis>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
In the main Bugzilla directory, you should:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block:
<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>
</itemizedlist>
</listitem>
After installing, check to see if you can view the file
<filename>
localconfig
</filename>
in your web browser (e.g.:
<ulink
url=
"http://bugzilla.mozilla.org/localconfig"
>
http://bugzilla.mozilla.org/localconfig
</ulink>
<listitem>
<para>
In
<filename
class=
"directory"
>
data
</filename>
:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block everything
</para>
</listitem>
<listitem>
<para>
But allow:
<simplelist
type=
"inline"
>
<member><filename>
duplicates.rdf
</filename></member>
</simplelist>
</para>
</listitem>
</itemizedlist>
</listitem>
). 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>
<listitem>
<para>
In
<filename
class=
"directory"
>
data/webdot
</filename>
:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
If you use a remote webdot server:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block everything
</para>
</listitem>
<listitem>
<para>
But allow
<simplelist
type=
"inline"
>
<member><filename>
*.dot
</filename></member>
</simplelist>
only for the remote webdot server
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Otherwise, if you use a local GraphViz:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block everything
</para>
</listitem>
<listitem>
<para>
But allow:
<simplelist
type=
"inline"
>
<member><filename>
*.png
</filename></member>
<member><filename>
*.gif
</filename></member>
<member><filename>
*.jpg
</filename></member>
<member><filename>
*.map
</filename></member>
</simplelist>
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
And if you don't use any dot:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block everything
</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
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
<filename>
localconfig
</filename>
file,
then Bugzilla will have to make certain files world readable and/or
writable.
<emphasis>
THIS IS INSECURE!
</emphasis>
<para>
In
<filename
class=
"directory"
>
Bugzilla
</filename>
:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block everything
</para>
</listitem>
</itemizedlist>
</listitem>
. This means that anyone who can get access to your system can do
whatever they want to your Bugzilla installation.
</para>
<listitem>
<para>
In
<filename
class=
"directory"
>
template
</filename>
:
</para>
<itemizedlist
spacing=
"compact"
>
<listitem>
<para>
Block everything
</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<note>
<para>
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.
</para>
</note>
<tip>
<para>
Bugzilla ships with the ability to generate
<filename>
.htaccess
</filename>
files instructing
<glossterm
linkend=
"gloss-apache"
>
Apache
</glossterm>
which files
should and should not be accessible. For more information, see
<xref
linkend=
"http-apache"
/>
.
</para>
</tip>
<para>
On Apache, you can use
<filename>
.htaccess
</filename>
files to
protect access to these directories, as outlined in Bugs
<ulink
url=
"http://bugzilla.mozilla.org/show_bug.cgi?id=57161"
>
57161
</ulink>
and
<ulink
url=
"http://bugzilla.mozilla.org/show_bug.cgi?id=186383"
>
186383
</ulink>
for the
<filename>
localconfig
</filename>
file, and
<ulink
url=
"http://bugzilla.mozilla.org/show_bug.cgi?id=65572"
>
Bug
65572
</ulink>
for adequate protection in your
<filename>
data/
</filename>
directory.
Also, don't forget about the
<filename>
template/
</filename>
and
<filename>
Bugzilla/
</filename>
directories and to allow access to the
<filename>
data/webdot
</filename>
directory for the
<computeroutput>
192.20.225.10
</computeroutput>
IP address if you are
using webdot from research.att.com. The easiest way to
accomplish this is to set
<function>
$create_htaccess
</function>
to 1
in
<filename>
localconfig
</filename>
. However, the information below
is provided for those that want to know exactly what is created.
</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><filename>
$BUGZILLA_HOME/.htaccess
</filename>
<programlisting>
<![CDATA[
# don't allow people to retrieve non-cgi executable files or our private data
<FilesMatch ^(.*\.pl|.*localconfig.*|processmail|runtests.sh)$>
deny from all
</FilesMatch>
<FilesMatch
^(localconfig.js|localconfig.rdf)$
>
allow from all
</FilesMatch>
]]>
</programlisting>
</para>
<para><filename>
$BUGZILLA_HOME/data/.htaccess
</filename>
<programlisting>
<![CDATA[
# nothing in this directory is retrievable unless overriden by an .htaccess
# in a subdirectory; the only exception is duplicates.rdf, which is used by
# duplicates.xul and must be loadable over the web
deny from all
<Files duplicates.rdf>
allow from all
</Files>
]]>
</programlisting>
</para>
<para><filename>
$BUGZILLA_HOME/data/webdot
</filename>
<programlisting>
<![CDATA[
# Restrict access to .dot files to the public webdot server at research.att.com
# if research.att.com ever changed their IP, or if you use a different
# webdot server, you'll need to edit this
<FilesMatch ^[0-9]+\.dot$>
Allow from 192.20.225.10
Deny from all
</FilesMatch>
# Allow access by a local copy of 'dot' to .png, .gif, .jpg, and
# .map files
<FilesMatch
^[0-9]+\.(png|gif|jpg|map)$
>
Allow from all
</FilesMatch>
# And no directory listings, either.
Deny from all
]]>
</programlisting>
</para>
<para><filename>
$BUGZILLA_HOME/Bugzilla/.htaccess
</filename>
<programlisting>
# nothing in this directory is retrievable unless overriden by an .htaccess
# in a subdirectory
deny from all
</programlisting>
<para>
You should test to make sure that the files mentioned above are
not accessible from the Internet, especially your
<filename>
localconfig
</filename>
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
<ulink
url=
"http://bugzilla.mozilla.org/localconfig"
/>
. You should
get a
<errorcode>
403
</errorcode>
<errorname>
Forbidden
</errorname>
error.
</para>
<para><filename>
$BUGZILLA_HOME/template/.htaccess
</filename>
<programlisting>
# nothing in this directory is retrievable unless overriden by an .htaccess
# in a subdirectory
deny from all
</programlisting>
<caution>
<para>
Not following the instructions in this section, including
testing, may result in sensitive information being globally
accessible.
</para>
</caution>
</listitem>
</orderedlist>
<tip>
<para>
You should check
<xref
linkend=
"http"
/>
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.
</para>
</tip>
</section>
</section>
<section
id=
"cust-templates"
>
...
...
@@ -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.:
<programlisting>
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:
<programlisting>
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.
sg
ml" "book" "chapter")
sgml-parent-document:("Bugzilla-Guide.
x
ml" "book" "chapter")
sgml-shorttag:t
sgml-tag-region-if-active:t
End:
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment