HaFrWiki:Community portal

From HaFrWiki
Jump to: navigation, search

Why a Wiki for yourself?

  1. For myself!
    • At home or not, I can use any computer with an internet connection to read and/or write pages containing knowledge I have collected. A Wiki gives any user the possibility to access and share information anywhere in the world with anybody.
    • I am using 2 wiki's at this moment,
      • An Intranet version at home on my MacBookPro as an extension for my mind.
      • An Internet version at One.com for sharing Information with others.
  2. Sharing information with people I like!
    • Meaning not everybody can share his ideas here. To share information you need my permission to edit/change pages. if you want to reach me, you can use email.
  3. I am convinced wikis, especially WikiPedia, have an added value to humanity.

Initially the Talk-pages have been open to add/edit/submit action by all users. Unfortunately I am forced to close these actions for not-registered users due to abuse by misbehaving users. Sorry, but they leave me no other choice!

Portal and Security

Everyone can help to build My-Harm-Wiki into a better site by editing the existing articles. The information of this wiki is partly public shared, partly shared to a selected group and partly strictly personal. These facts make it impossible to grant access to anybody. Also not everybody who has read-access to articles is also allowed to edit these pages or even to create new pages. So I need a Security Model for my wikis!

Security Model

MediaWiki does not support or have a Security Model and also MediaWiki is not written to support a Security Model [1]. For my old Wiki-Site I had written a Lean-and-Mean Access Control mechanism and although MediaWiki does not encourage writing such an model I decided to create one based on the Role Based Access Control Model (RBAC Model). The model extents 2 MediaWiki Hooks:

  1. MediaWikiPerformAction is made responsible for checking the user-rights for normal pages. Based on the existing UserGroups and Categories and new created UserGroup-Categories relation. See RBAC for Categories for details.
  2. BeforeInitialize is made responsible for checking the user-rights for special pages. Based on the existing UserGroups and new created UserGroup-Special-Pages relation. See RBAC for Special Pages for details.

RBAC for Categories


The RBAC model works as follows. The first 2 most important implementations for the model is:

  • Every User has at least one Role.
  • Every wiki-Article belongs to at least one Category.

Look at the bottom of this page. You see that this page belongs to the Category Index. This relation has to be made when the pages is created. It is always possible to change this page-category relation.
The relation between User and Role (which is named UserGroup in this wiki) is created and maintained by the wiki-administrator and is hidden for the user.

Now the Roles (or UserGroups) has to have a relation to the Categories. But this relation needs an extra attribute the so-called access-privilege. This access privilege is based on the database access as described by the Create CRUD matrix (Create, Read, Update and Delete). This structure has been created using extsing and new functionali ty in the MediaWiki database.

Tables
User UserGroup Ug2Cat CategoryLink Page
i user_id <--->
s user_name  
s user_real_name  
b user_password  
b user_new_password  
i ug_user  
s ug_group <--->
 
 
 
i u2g_id  
s u2g_ug  
i u2g_cat <--->
i u2g_right  
s u2g_description  
 
i cl_from <--->
s cl_to  
e cl_type  
 
 
 
i page_id  
i page_namespace  
s page_title  
b page_restrictions  
i page_counter  


Description/Explanation/Illustration
The field abbreviations for the column type are:
  • b : tinyblob
  • e : enum
  • i : Integer
  • s : varchar(255)
  u2g_right is an enum. The values are stored in the table CrudRights' and have the values:
  • 0 : No-CRUD rights
  • 1 : create
  • 2 : read
  • 4 : update
  • 8 : delete

The tables User, Usergroup, CategoryLinks and Page are in the basic MediaWiki implementation. The tables Ug2Cat and CrudRight are new.

The presented RBAC Schema is very abstract and it may be difficult to be used without giving an example. Therefor all database-tables are shown below and their changes for usage of the RBAC model. In this example the imaginary Usergroup HAL and Category WorkSpace are introduced [2].

User

The table User is not altered. Every new user can be added, deleted, changed as usual.

UserGroup

The structure of the UserGroup table is not altered. Only the content has to be changed (by changing the LocalSetting.php file).

To make optimal usage of the power of the MediaWiki Groups and the RBAC implementation it is necessary to limit the normal usage of the users.
Therefor it is needed to alter/add the settings of the wgGroupPermissions in LocalSettings.php.
Please note:

  • In a standard MediaWiki implementation the wgGroupPermission is not present, so you'll need to add these statements.
  • In this example-implementation a user can not create an account. Only the sysop can.
/*
** Implicit group for all visitors
*/
$wgGroupPermissions['*'       ]['createaccount'] = false;
$wgGroupPermissions['*'       ]['createpage'   ] = false;
$wgGroupPermissions['*'       ]['createtalk'   ] = false;
$wgGroupPermissions['*'       ]['read'         ] = true;
$wgGroupPermissions['*'       ]['edit'         ] = false;
$wgGroupPermissions['*'       ]['writeapi'     ] = false;
 
/*
** Implicit group for all logged-in accounts
*/
$wgGroupPermissions['user'    ]['move']          = false;
$wgGroupPermissions['user'    ]['read']          = true;
$wgGroupPermissions['user'    ]['edit']          = false;
$wgGroupPermissions['user'    ]['upload']        = false;

/*
** Makes every User a member of the bot group
*/
$wgGroupPermissions['bot'     ]['bot']           = true;
$wgGroupPermissions['bot'     ]['edit']          = true;
$wgGroupPermissions['bot'     ]['createpage']    = true;
$wgGroupPermissions['bot'     ]['createtalk']    = true;

If you make every new-user member of the bot-group, he/she can do basic editing. The next step is to create a new usergroup with explicit rights to be used in combination with the attached category (See later). In the examples here presented this usergroup is called 'HAL'. See for details of Usergroups:

  • User Rights on Mediawiki descpription for the LocalSettings.php.
    The $wgGroupPermissions is an associative array, controlling permissions for creating and editing pages for your different user groups. In this array, custom permission levels can be created, and permission levels for the different user groups can be set.
  • Help User Rights description on Mediawiki.

UserGroup to Category

Table Ug2Cat Description
This table is the key for the RBAC implementation. It is used for implementation of the functions:
  • Usergroup has all, partial or none CRUD-rights to all categories
  • UserGroup has all, partial or none CRUD-rights to a specific category
  • All user groups have all, partial or none CRUD-rights to a specific category.
Name Type Description
u2g_id int(10) Auto increment Row id
u2g_ug char(16) Usergroup name
u2g_cat int(10) Category name id
u2g_right int(10) Sum of enumerated rights
u2g_description varchar(64) Short description

Scenario examples

Scenario u2g_id u2g_ug u2g_cat u2g_right u2g_description
UserGroup has access to all Categories Auto sysop 0 15 Sysop has all CRUD-access (15) to all Categories (0)
UserGroup has access to 1 Category Auto hal 26 15 HAL has all CRUD-access (15) to Category WorkSpace (26)
Every UserGroup has access to 1 Category Auto * 9 2 Everyone (*) has CRUD-read-access (2) to Category Help (9)

A typical implementation of the ug_cat:

INSERT into `ug2cat` (`u2g_ug`, `u2g_cat`, `u2g_right`, `u2g_description`) VALUES 
( 'sysop'  ,                                                                             0, 15, "Sysop has all-access to all categories"),
( 'hal'    ,  (Select `cat_id` FROM `category` WHERE LOWER(`cat_title`) = 'workspace'    ), 15, "All-Access-Rights to category WorkSpace"),
( '*'      ,  (Select `cat_id` FROM `category` WHERE LOWER(`cat_title`) = 'help'         ),  2, "Everyone has Read (view) Access-Rights to category Help"); 

CategoryLink

The tables is not altered. The content is changed by adding a category to every wiki page.

Page

The table is not altered. The content is maintained by the normal wiki handling.

RBAC for Special Pages

MediaWiki adds many Special Pages. Nice for adding extra information, but also a security-issue when such an extension or extra page does not follow the architectural design of MediaWiki. The default access for Special Pages is forbidden, the u2g_spec script for creating entries gives the basic security for MediaWiki, not for all other extensions.

User

The table User is not altered. Every new user can be added, deleted, changed as usual.

UserGroup

The table UserGroup is not altered. See for additional information UserGroup.

UserGroup to Special Page

Table Ug2Spec Description
This table is the key for the RBAC implementation for the special pages. It is used for implementation of the functions:
  • Usergroup has all, partial or none CRUD rights to all Special Pages
  • Usergroup has all, partial or none CRUD rights to a specific Special Pages
  • All Usergroups have all, partial, or none CRUD rights to a specific Special Page.
Name Type Description
u2g_id int(10) Auto increment Row id
u2g_ug char(16) Usergroup name
u2g_spec char(25) Special Page string
u2g_right int(10) Sum of enumerated rights
u2g_namespace char(25) NS_SPECIAL
u2g_description varchar(64) Short description

Scenario examples

Scenario u2g_id u2g_ug u2g_spec u2g_right u2g_namespace u2g_description
UserGroup has access to all Special Pages Auto sysop * 15 NS_SPECIAL Sysop has all CRUD-access (15) to all SPs
UserGroup has access to 1 Special Page Auto hal Contributions 15 NS_SPECIAL HAL has all CRUD-access (15) to SP-Contributions
Every UserGroup has access to 1 Special Page Auto * Userlogin 2 NS_SPECIAL Everyone (*) has Read-access (2) to SP-Userlogin.

Code changes

The installation of WikiRBAC does not require additional changes to the MediaWiki code except for the file LocalSettings.php.

  • Adding of the additional files for WikiRBAC by adding
    require_one('/extensions/WikiRBAC/WikiRBAC.php');
    .
  • Adding of the wgGroupPermissions as described above.

The installation requires the addition of 2 extra tables to the MediaWiki Database.

  • ug2cat
  • ug2spec

The SQL-statements to create the 2 tables are provided in the installation (RBAC_CRUD.sql).

The WikiRBAC uses the MediaWiki Hooks to add the RBAC-Functionality to MediaWiki. The 2-hooks used are:

  • 'MediaWikiPerformAction' which is used for accessing of normal pages using the the UserGroup to Categories RBAC Model
  • 'BeforeInitialize', which is used for accessing the Special Pages using the UserGroup to Special Pages RBAC Model.

The WikiRBAC consists on the files:

  • Util.php, Utility class for logging, and static implemenations
  • WikiRBAC.php, main entry point for both hooks
  • WikiRBAC.Hooks.php, Currently not used, but basics for testing
  • WikiRBAC.i18n.php, Language specific texts used in the extension. Currently only English and Dutch support.
  • WikiRBAC.i18n.magic.php, Magic functions
  • WikiRBAC.settings.php

and there are changes made to:

  • LocalSetting.php

Security limitations

As earlier stated MediaWiki is not a Content Management Systems (CMS) [3]. The following issues have to be addressed to secure your website.

Atom/RSS Feeds

There are two feeds:

  • Recent changes special pages
  • New pages
  • Optional additional feeds provided by extensions.

The problem of the feeds are that the additional check for access is not made (MediaWikiPerformAction). There are 2 options, both not optimal to cover this problem:

  • Disable the Special Pages 'NewPages' and 'RecentChanges' for Read-Access to all users.
  • Disable the Atom/RSS feed generation to all users. In the LocalSetting add the lines:
$wgFeed = false;
$wgFeedClasses = array();

It should be nice as a MediaWiki Hook is added into the Atom/RSS feed generation.

See also

top

  • DbTrace for MediaWiki, A private tool for MediaWiki monitoring users and page views. Statistic information of Wiki-Visitors and Wiki-Page-Views
  • RBAC, Role Based Access Control description and examples.

Reference

top

  1. Mediawiki Extension Page Security issues on MediaWiki Websites
  2. Every intended reference to movie 2001 a Space Odyssey is coincidence.
  3. MediaWiki, Security issues with authorization extensions.