From 5f90e90f0a8c4d57568799ec5056ea9f4f762166 Mon Sep 17 00:00:00 2001 From: "jake%bugzilla.org" <> Date: Fri, 4 Apr 2008 11:47:12 +0000 Subject: Bug 186672 - Update security docs to warn about editor backups and bring them up to date. a=justdave --- docs/en/xml/administration.xml | 179 +++++++++++++++++++++++++++++------------ 1 file changed, 127 insertions(+), 52 deletions(-) diff --git a/docs/en/xml/administration.xml b/docs/en/xml/administration.xml index b09de7666..05096981f 100644 --- a/docs/en/xml/administration.xml +++ b/docs/en/xml/administration.xml @@ -773,12 +773,6 @@ 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. - - There is no substitute for understanding the tools on your @@ -791,9 +785,9 @@ - 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. + 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. @@ -821,27 +815,45 @@ Ensure you have adequate access controls for the - $BUGZILLA_HOME/data/ directory, as well as the - $BUGZILLA_HOME/localconfig file. + $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. + files under $BUGZILLA_HOME/data/ store sensitive + information. + + + Also, beware that some text editors create backup files in the + current working directory so you need to also secure files like + localconfig~. - 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. + + Simply blocking .*localconfig.* + won't work because the QuickSearch feature requires the web browser + to be able to retrieve localconfig.js and + others may be introduced in the future (see + bug + 186383 for more information. + + + + 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, + .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.: + localconfig in your web browser (e.g.: http://bugzilla.mozilla.org/localconfig @@ -850,11 +862,14 @@ 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. + 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 @@ -867,44 +882,104 @@ installation. - On Apache, you can use .htaccess files to protect access to - these directories, as outlined in - Bug - 57161 + On Apache, you can use .htaccess files to + protect access to these directories, as outlined in Bugs + + 57161 and + + 186383 - for the localconfig file, and + for the localconfig file, and Bug 65572 - for adequate protection in your data/ directory. + for adequate protection in your data/ directory. + Also, don't forget about the template/ and + Bugzilla/ directories and to allow access to the + data/webdot directory for the + 192.20.225.10 IP address if you are + using webdot from research.att.com. The easiest way to + accomplish this is to set $create_htaccess to 1 + in localconfig. However, the information below + is provided for those that want to know exactly what is created. + 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. - 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 + $BUGZILLA_HOME/.htaccess + + deny from all + + + allow from all + + ]]> + + + $BUGZILLA_HOME/data/.htaccess + + allow from all + + ]]> - 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 + $BUGZILLA_HOME/data/webdot + + Allow from 192.20.225.10 + Deny from all + + +# Allow access by a local copy of 'dot' to .png, .gif, .jpg, and +# .map files + + Allow from all + + +# And no directory listings, either. +Deny from all + ]]> + $BUGZILLA_HOME/Bugzilla/.htaccess + +# nothing in this directory is retrievable unless overriden by an .htaccess +# in a subdirectory +deny from all + + + + $BUGZILLA_HOME/template/.htaccess + +# nothing in this directory is retrievable unless overriden by an .htaccess +# in a subdirectory +deny from all + + +
- Template Customisation + Template Customization - One of the large changes for 2.16 was the templatisation of the + One of the large changes for 2.16 was the templatization of the entire user-facing UI, using the Template Toolkit. Administrators can now configure the look and feel of Bugzilla without @@ -913,9 +988,9 @@ - Templatisation also makes localised versions of Bugzilla possible, + Templatization also makes localized versions of Bugzilla possible, for the first time. In the future, a Bugzilla installation may - have templates installed for multiple localisations, and select + have templates installed for multiple localizations, and select which ones to use based on the user's browser language setting. @@ -926,7 +1001,7 @@ and which you use depends mainly on how you upgrade Bugzilla. The template directory structure is that there's a top level directory, template, which contains a directory for - each installed localisation. The default English templates are + each installed localization. The default English templates are therefore in en. Underneath that, there is the default directory and optionally the custom directory. The default @@ -936,7 +1011,7 @@ - The first method of making customisations is to directly edit the + The first method of making customizations is to directly edit the templates in template/en/default. This is probably the best method for small changes if you are going to use the CVS method of upgrading, because if you then execute a @@ -1089,7 +1164,7 @@ There are a few templates you may be particularly interested in - customising for your installation. + customizing for your installation. @@ -1110,7 +1185,7 @@ global/banner.html.tmpl: This contains the "banner", the part of the header that appears at the top of all Bugzilla pages. The default banner is reasonably - barren, so you'll probably want to customise this to give your + barren, so you'll probably want to customize this to give your installation a distinctive look and feel. It is recommended you preserve the Bugzilla version number in some form so the version you are running can be determined, and users know what docs to read. @@ -1191,7 +1266,7 @@
- Change Permission Customisation + Change Permission Customization @@ -1213,7 +1288,7 @@ - For maximum flexibility, customising this means editing Bugzilla's Perl + For maximum flexibility, customizing this means editing Bugzilla's Perl code. This gives the administrator complete control over exactly who is allowed to do what. The relevant function is called CheckCanChangeField(), @@ -1245,7 +1320,7 @@ - More complex customisations are not much harder. Basically, you add + More complex customizations are not much harder. Basically, you add a check in the right place in the function, i.e. after all the variables you are using have been set up. So, don't look at $ownerid before $ownerid has been obtained from the database. You can either add a @@ -1280,7 +1355,7 @@ For a list of possible field names, look in data/versioncache for the list called @::log_columns. If you need help writing custom - rules for your organisation, ask in the newsgroup. + rules for your organization, ask in the newsgroup.
@@ -1299,12 +1374,12 @@ However, things get a bit more complicated if you've made changes to Bugzilla's code. In this case, you may have to re-make or - reapply those changes. One good method is to take a diff of your customised + reapply those changes. One good method is to take a diff of your customized version against the original, so you can survey all that you've changed. - Hopefully, templatisation will reduce the need for + Hopefully, templatization will reduce the need for this in the future. - From version 2.8 onwards, Bugzilla databases can be automatically + From version 2.8 onward, Bugzilla databases can be automatically carried forward during an upgrade. However, because the developers of Bugzilla are constantly adding new tables, columns and fields, you'll probably get SQL errors if you just -- cgit v1.2.3-24-g4f1b