################################################################# # # # BUGGER V1.0 # # Advanced Features # # # # Document Author: Ben Tasker # # Document Date: 10/12/2009 # # Filename: 20091210_BUGGER_advanced_features.txt # # # ################################################################# Contents ---------- - Aim - Backups - Site Administrators - Logging Aim ----- The aim of this document is to detail the intended implementation of BUGGER's 'advanced' features. The term 'advanced' does not necessarily imply innovative features, but is used purely to refer to features that whilst useful do (or should) not affect the average end users experience of using the system. In other words it refers to functionality that is not part of the core aim of BUGGER (Project Management). Backups -------- BUGGERs backup functionality will allow Administrators to download a tarball containing an (almost) complete backup of the underlying database. The only table that will be omitted from this backup is the table containing the password hash used to clear BUGGERs logs. This will be omitted in order to prevent a malicious administrator from downloading the backup in order to try and crack the hash. The backup functionality will essentially work by retrieving each of the tables in turn, and then placing them into a Gzipped tarball. This file will then be streamed to the requesting user. The process will happen in the following order mkdir $TEMPDIR/BUGGER.Backup."$$" wget TABLE1 (repeat for each table) tar -cf $TEMPDIR/BUGGER.Backup."$$" BUGGER_backup.$$.tar gzip BUGGER_backup.$$.tar [Optional Subroutine] Stream backup to user The Optional Subroutine will create a local copy of the backup file. This subroutine will be enabled/disabled by the administrator in BUGGERS config file. If a local backup is to be made, the administrator will have specified the path in which it should be stored. It will then be created with a filename in the following format BUGGER_DBbackup_$DATE_TIME.tar.gz DATE will be in the format YYYYMMDD TIME will be in the format HHMM There will also be an option to disable this feature entirely. In order to be effective it will be created so that it can not be updated remotely. Because users must be Administrators to stream the backup, creating an override that can be remotely toggled would negate the entire point in the Override. Site Administrators --------------------- If being unable to remotely update the backup option proves unpopular, an additional security level will be created - Site Administrator. The Backup Override option will then be remotely updateable, but only by Site Administrators. Similarly BUGGERs config will be updated to only allow alterations by Site Administrators. This may however lead to a requirement for the Configuration file to be split into two in order to allow Ordinary Administrators to update certain elements. If this is the case, then the 'lesser privileged' configuration should be moved into the database, with caching enabled. Implementing this will allow the main site Administrator to complete a large portion of their maintenance remotely, and also to allow certain users to create/edit user accounts without handing over the keys to the entire site. Logging -------- To enable to BUGGER system administrator to monitor and manage security settings effectively, a number of logging options will be available. - Admin features logging - Developer features logging - Moderator features logging - User feature logging (logged in users) - Basic actions logging All logs will log the following details; + Relevant Log Level (i.e. Admin) + Username (where available) + Remote IP + Remote Hostname + Time + Date + Action (i.e. Post Bug, Post Comment) + Record ID (i.e. Bug ID, Comment I.D where available) + Success/Fail + Additional (Will vary with page, each set of information will be prefixed with what it is, i.e. Captcha: 2+2 Response: 12) Each logging level will be individually toggleable, so that the Administrative user can enable any combination that he/she desires. Admin Features logging will record all actions undertaken on pages that require Administrative privileges (Config changes/User Changes etc.) This level will also log attempts to access privileged pages by users who lack administrator access rights. Developer Features will will record all actions undertaken on pages that require Developer privileges (Project News/Bug Updates etc.) This level will also log attempts to access privileged pages by users who lack developer access rights. Moderator Features logging will record all actions undertaken on pages that require Moderator privileges (Comment Deletion etc.) This level will also log attempts to access privileged pages by users who lack moderator access rights. User Features logging will record all actions undertaken on pages that require the user to be logged in (set by Administrator), this will log Bug Reports, Comment Posts etc. Basic Features logging will record all actions undertaken on pages that do not require the user to be logged in (Depending on settings this could include Bug Reports, Comment Posting etc.) In order to log every action, each of these logging levels must be enabled. Additionally, should the Security Group 'Site Administrator' be added to BUGGER a corresponding logging level will also be added. - Log Storage The Logs will be inserted into the database. The site Administrator will be able to specify whether this happens in real time or whether it should be batched. Real time will mean that audit logs can be checked at any time of the day, but will lead to an increase in page response time where logging is enabled. Batch processing will push the logs to a locally held text file. At a preset time the system will process the log file and insert each entry into the database (by means of a Cron Job). The Administrator will also be given the ability to force a Batch transfer (i.e. run the processing script on demand). - Log Security The logs will be visible to all Administrators (or Site Administrators should that Security Group be added). There will be a password protected function to clear the logs. This password will be set by the BUGGER system administrator and stored in a seperate table to the normal user details. This table will NOT be exported as part of streamed backups. It will of course be backed up by the Claims_DB backup process. There will be no 'Forgotten Password' function for the Log clearance password. Resetting this password will require shell access to either the Webserver or the Database server itself. A script will be provided to allow regeneration of the password hash. This should help prevent abuse by malicious users (so long as the Claims_DB Server has been properly secured - User authentication etc.) - Log Reporting Administrators will be able to view the logs in a number of ways; View full log View only failed transactions View only Successful transactions View all entries by user View all entries without a username View failed Captchas View Entries after date View entries between dates View entries by Log Level ################################################################# # # # DOCUMENT END # # Copyright Ben Tasker # # Released under the GNU GPL V3 # # See http://benscomputer.no-ip.org/LICENSE3 # # # #################################################################