Hardening new Roles system: Difference between revisions

Revision as of 08:24, 10 June 2011

Hardening a role, refers to limiting the ability of a role to assign or to aquire permissions.

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.

The solution has two parts: educate admins and teachers about the risks associated with each capability and optionally allow central management of risks.

Risk bitmask in capabilities

Add risk bitmask field to each capability. Each bit indicates presence of different risk associated with given capability.

Basic risks

RISK_SPAM - user can add visible content to site, send messages to other users; originally protected by !isguest()
RISK_PERSONAL - access to private personal information - ex: backups with user details, non public information in profile (hidden email), etc.; originally protected by isteacher()
RISK_XSS - user can submit content that is not cleaned (both HTML with active content and unprotected files); originally protected by isteacher()
RISK_CONFIG - user can change global configuration, actions are missing sanity checks
RISK_MANAGETRUST - manage trust bitmasks of other users
RISK_DATALOSS - can destroy large amounts of information that cannot easily be recovered.

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.

Implementation

add new LONGINT column riskbitmask to table capabilities (DONE)
define risks and assign them to capabilities in mod/xxx/db/access.php and lib/db/access.php (DONE)
link wiki pages with explanation to each risk from capabilities page
allow risk based filtering of capabilities admin/roles/manage.php (optional)

The user interface will be minimal, icons and maybe colors indicating each risk together with description links which we need anyway. Developers are deciding about the risks, the risk assignment is hardcoded in access.php description file, no GUI needed to change risks.

Benefits

proper documentation of risks associated with capabilities, easy to explain
solid foundation for regular code audits (mainly XSS prevention and personal information disclosure)

User trust bitmask

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().

Implementation

add new LONGINT column trustbitmask to user table
add capability moodle/site:managetrustbitmasks with RISK_MANAGETRUST risk
add trust checks to has_capability() and require_capability()
add GUI
- switch in global configuration to enable trust bitmask checking
- preseting of trust bitmask for new users
- changing of trust bitmasks
- add trust bitmask setting to user/edit.php
- request trust level change form - something like new course request (optional)
fix upgrade to assign trust bitmaps based on original teacher or administrator rights
patch user import script and synchronizations (optional)

Benefits

This part is optional and can be implemented later.
Trust manager or admin has full control over potentially dangerous capabilities - it is necessary for large sites (or connected sites in the future).
Trust bitmask mechanism can be turned off by single configuration switch (both GUI and checks) - needed for small insecure workshop sites.
General protection against future bugs in role and capability framework or user errors when configuring roles.

Note: trusttext moved to its own page at Trusttext cleaning bypass

@@ Line 1: / Line 1: @@
-New roles add great freedom when assigning rights 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 without any restrictions.
+Hardening a role, refers to limiting the ability of a role to assign or to aquire permissions.
-==Proposed solution 1==
+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.
-Assign trust level to each user and capability. Add trust level checks to has_capability() and require_capability().
-===Implementation===
+The solution has two parts: educate admins and teachers about the risks associated with each capability and optionally allow central management of risks.
-* define basic trust levels (as integer constants)
-** minimal - not logged-in, guests
+==Risk bitmask in capabilities==
-** standard - students and non-editing teachers (must not be able to add HTML with javascript, can not upload files to coursefile area)
+Add risk bitmask field to each capability. Each bit indicates presence of different risk associated with given capability.
-** high - teachers adding active content and handling sensitive information (backups, editing of activities and resources, uploading of course files, creating courses, etc.)
-** absolute - usually administrators and trust level managers only
+===Basic risks===
-* add new column ''trustlevel'' to ''user'' table
+* '''RISK_SPAM''' - user can add visible content to site, send messages to other users; originally protected by !isguest()
-* add new column ''requiredtrustlevel'' to table ''capabilities''
+* '''RISK_PERSONAL''' - access to private personal information - ex: backups with user details, non public information in profile (hidden email), etc.; originally protected by isteacher()
-* fix role management GUI
+* '''RISK_XSS''' - user can submit content that is not cleaned (both HTML with active content and unprotected files); originally protected by isteacher()
-** indicate required trust level next to each capability (different color and label or icon)
+* '''RISK_CONFIG''' - user can change global configuration, actions are missing sanity checks
-** allow filtering of capabilities based on trust level required
+* '''RISK_MANAGETRUST''' - manage trust bitmasks of other users
-* add ''moodle/site:managetrustlevel'' with required absolute trust level
+* '''RISK_DATALOSS''' - can destroy large amounts of information that cannot easily be recovered.
-* add trust level management GUI
-** predefined trust level for new users
-** changing of trust level (also from user/edit page)
-** request trust level change form (something like new course request)
-* add trust level checks to has_capability() and require_capability() (veto when user does not have required trust level)
-* assign levels based on legacy capabilities during upgrade
-* do security audit of each capability in modules and core; set proper required levels (this is going to be the hardest part)
-===Benefits===
+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.
-# Easy to implement, administer and explain to teachers compared to implementation based on capabilities.
-# Trust level manager has full control over potentially dangerous capabilities - it is necessary for large sites (or connected sites in the future).
-# Trust level mechanism can be turned off by assigning high level to all users except admins - needed for small insecure ''workshop'' sites.
-# Security audits could concentrate on standard and minimal capabilities.
-# Module authors will be forced to think about security when defining capabilities.
-== Proposed solution 1a ==
+===Implementation===
+* add new LONGINT column ''riskbitmask'' to table ''capabilities'' (DONE)
+* define risks and assign them to capabilities in mod/xxx/db/access.php and lib/db/access.php (DONE)
+* link wiki pages with explanation to each risk from capabilities page
+* allow risk based filtering of capabilities admin/roles/manage.php (optional)
-See [[Talk:Hardening_new_Roles_system|talk page]].
+The user interface will be minimal, icons and maybe colors indicating each risk together with description links which we need anyway.
+Developers are deciding about the risks, the risk assignment is hardcoded in access.php description file, no GUI needed to change risks.
-==Proposed solution 2==
+===Benefits===
-# Have one new capability called "trusttext" or something.
+# proper documentation of risks associated with capabilities, easy to explain
-# Certain roles who you trust to edit text and allow to have Javascript, EMBED etc can have permission for this capability set to "allow" (these people are generally teachers).
+# solid foundation for regular code audits (mainly XSS prevention and personal information disclosure)
-# When saving a text from a user, modules can call a function on the text and insert a special tag (eg ####TRUST#####) if the current user is trusted (and actively REMOVE all such tags if the user is NOT trusted).
-# When displaying the text with format_text(), a new parameter needs to be passed to enable the trust system ($options->usetrust = true).
-# If $options->usetrust is present, each text is checked for ####TRUST#### in the text and output is cleaned appropriately, depending on whether the tag was found.  If this new parameter is not present (eg in old modules or 3rd party modules) then all such tags are removed and the text is always fully cleaned.
-# For caching, the text is stored in the final form as it is now.
-===Example===
+==User trust bitmask==
-====Storing the text====
+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().
-Here is the original text from the user:
-  Elephant says &lt;script>alert('hello')&lt;/script>
-Here it's converted before storage:
+===Implementation===
-  $text = apply_trust_to_text($text);
+* add new LONGINT column ''trustbitmask'' to ''user'' table
+* add capability ''moodle/site:managetrustbitmasks'' with RISK_MANAGETRUST risk
+* add trust checks to has_capability() and require_capability()
+* add GUI
+** switch in global configuration to enable trust bitmask checking
+** preseting of trust bitmask for new users
+** changing of trust bitmasks
+** add trust bitmask setting to user/edit.php
+** request trust level change form - something like new course request (optional)
+* fix upgrade to assign trust bitmaps based on original teacher or administrator rights
+* patch user import script and synchronizations (optional)
-For a trusted user, this will return this text for storage:
+===Benefits===
-  ####TRUST####Elephant says &lt;script>alert('hello')&lt;/script>
+# This part is optional and can be implemented later.
+# Trust manager or admin has full control over potentially dangerous capabilities - it is necessary for large sites (or connected sites in the future).
+# Trust bitmask mechanism can be turned off by single configuration switch (both GUI and checks) - needed for small insecure workshop sites.
+# General protection against future bugs in role and capability framework or user errors when configuring roles.
-For an untrusted user, this will return:
-  Elephant says &lt;script>alert('hello')&lt;/script>
-====Showing the text====
+''Note: trusttext moved to its own page at [[Trusttext cleaning bypass]]''
-If the tag is found AND the code is trust-enabled then cleaning is NOT done, and only that special tag is removed before output.
-  Elephant says &lt;script>alert('hello')&lt;/script>
-If not found then cleaning is done fully (as it is now in Moodle):
+[[Category:Roles]]
-  Elephant says

Documentation

Hardening new Roles system: Difference between revisions

Revision as of 08:24, 10 June 2011

Contents

Risk bitmask in capabilities

Basic risks

Implementation

Benefits

User trust bitmask

Implementation

Benefits