http://wiki.mipt.ru/index.php?action=history&feed=atom&title=Development%3AHardening_new_Roles_systemDevelopment:Hardening new Roles system - История изменений2026-05-06T23:59:17ZИстория изменений этой страницы в викиMediaWiki 1.42.1http://wiki.mipt.ru/index.php?title=Development:Hardening_new_Roles_system&diff=11218&oldid=prevОлег Давидович: 1 версия импортирована2024-10-21T08:51:19Z<p>1 версия импортирована</p>
<table style="background-color: #fff; color: #202122;" data-mw="interface">
<tr class="diff-title" lang="ru">
<td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">← Предыдущая версия</td>
<td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">Версия от 08:51, 21 октября 2024</td>
</tr><tr><td colspan="2" class="diff-notice" lang="ru"><div class="mw-diff-empty">(нет различий)</div>
</td></tr></table>Олег Давидовичhttp://wiki.mipt.ru/index.php?title=Development:Hardening_new_Roles_system&diff=11217&oldid=prev1>TimHunt: /* Basic risks */2008-08-13T04:45:02Z<p><span dir="auto"><span class="autocomment">Basic risks</span></span></p>
<p><b>Новая страница</b></p><div>Hardening a role, refers to limiting the ability of a role to assign or to aquire permissions.<br />
<br />
New roles add great freedom when assigning capabilities to students. The problem might arise when students are assigned permission that allows adding of content that is not cleaned before display - such as editting Resources, adding activities, etc. They could then use any type of XSS attack to gain full administrative access quite easily.<br />
<br />
The solution has two parts: educate admins and teachers about the risks associated with each capability and optionally allow central management of risks.<br />
<br />
==Risk bitmask in capabilities==<br />
Add risk bitmask field to each capability. Each bit indicates presence of different risk associated with given capability.<br />
<br />
===Basic risks===<br />
* '''RISK_SPAM''' - user can add visible content to site, send messages to other users; originally protected by !isguest()<br />
* '''RISK_PERSONAL''' - access to private personal information - ex: backups with user details, non public information in profile (hidden email), etc.; originally protected by isteacher()<br />
* '''RISK_XSS''' - user can submit content that is not cleaned (both HTML with active content and unprotected files); originally protected by isteacher()<br />
* '''RISK_CONFIG''' - user can change global configuration, actions are missing sanity checks<br />
* '''RISK_MANAGETRUST''' - manage trust bitmasks of other users<br />
* '''RISK_DATALOSS''' - can destroy large amounts of information that cannot easily be recovered.<br />
<br />
In default configuration Guest role should have only capabilities without risks, Student roles also SPAM, Teacher roles PERSONAL and XSS too. Admins have all capabilitites by default.<br />
<br />
===Implementation===<br />
* add new LONGINT column ''riskbitmask'' to table ''capabilities'' (DONE)<br />
* define risks and assign them to capabilities in mod/xxx/db/access.php and lib/db/access.php (DONE)<br />
* link wiki pages with explanation to each risk from capabilities page<br />
* allow risk based filtering of capabilities admin/roles/manage.php (optional)<br />
<br />
The user interface will be minimal, icons and maybe colors indicating each risk together with description links which we need anyway.<br />
Developers are deciding about the risks, the risk assignment is hardcoded in access.php description file, no GUI needed to change risks.<br />
<br />
===Benefits===<br />
# proper documentation of risks associated with capabilities, easy to explain<br />
# solid foundation for regular code audits (mainly XSS prevention and personal information disclosure)<br />
<br />
==User trust bitmask==<br />
Indicate what kind of trust each user has. Match the risk bitmask of capability and user trust bitmask in both has_capability() and require_capability().<br />
<br />
===Implementation===<br />
* add new LONGINT column ''trustbitmask'' to ''user'' table<br />
* add capability ''moodle/site:managetrustbitmasks'' with RISK_MANAGETRUST risk<br />
* add trust checks to has_capability() and require_capability()<br />
* add GUI<br />
** switch in global configuration to enable trust bitmask checking<br />
** preseting of trust bitmask for new users<br />
** changing of trust bitmasks<br />
** add trust bitmask setting to user/edit.php<br />
** request trust level change form - something like new course request (optional)<br />
* fix upgrade to assign trust bitmaps based on original teacher or administrator rights<br />
* patch user import script and synchronizations (optional)<br />
<br />
===Benefits===<br />
# This part is optional and can be implemented later.<br />
# Trust manager or admin has full control over potentially dangerous capabilities - it is necessary for large sites (or connected sites in the future). <br />
# Trust bitmask mechanism can be turned off by single configuration switch (both GUI and checks) - needed for small insecure workshop sites.<br />
# General protection against future bugs in role and capability framework or user errors when configuring roles.<br />
<br />
<br />
''Note: trusttext moved to its own page at [[Trusttext cleaning bypass]]''<br />
[[Category:Developer|Hardening new Roles system]]<br />
[[Category:Roles]]</div>1>TimHunt