Difference between revisions of "Hardening new Roles system"

Jump to: navigation, search
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.
 
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.
  
==Proposed solution==
+
==Proposed solution 1==
 
Assign trust level to each user and capability. Add trust level checks to has_capability() and require_capability().
 
Assign trust level to each user and capability. Add trust level checks to has_capability() and require_capability().
  
Line 30: Line 30:
 
# Security audits could concentrate on standard and minimal capabilities.
 
# Security audits could concentrate on standard and minimal capabilities.
 
# Module authors will be forced to think about security when defining capabilities.
 
# Module authors will be forced to think about security when defining capabilities.
 +
 +
 +
==Proposed solution 2==
 +
# Have one new capability called "trusttext" or something.
 +
# 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).
 +
# When saving a text from a user, modules can call a function on the text ("hello world") and insert special tags if the current user is trusted, something like this:
 +
 +
  $text = mark_text_as_trusted($text);
 +
 +
  <div class="trusttext">hello</div>
 +
 +
# When showing the text with format_text(), each text is checked for these tags surrounding the whole text.
 +
# If found then cleaning is not done, and those tags are removed before output.
 +
# If not found then cleaning is done fully, then output.

Revision as of 07:50, 16 August 2006

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.

Proposed solution 1

Assign trust level to each user and capability. Add trust level checks to has_capability() and require_capability().

Implementation

  • define basic trust levels (as integer constants)
    • minimal - not logged-in, guests
    • standard - students and non-editing teachers (must not be able to add HTML with javascript, can not upload files to coursefile area)
    • 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
  • add new column trustlevel to user table
  • add new column requiredtrustlevel to table capabilities
  • fix role management GUI
    • indicate required trust level next to each capability (different color and label or icon)
    • allow filtering of capabilities based on trust level required
  • add moodle/site:managetrustlevel with required absolute trust level
  • 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

  1. Easy to implement, administer and explain to teachers compared to implementation based on capabilities.
  2. Trust level manager has full control over potentially dangerous capabilities - it is necessary for large sites (or connected sites in the future).
  3. Trust level mechanism can be turned off by assigning high level to all users except admins - needed for small insecure workshop sites.
  4. Security audits could concentrate on standard and minimal capabilities.
  5. Module authors will be forced to think about security when defining capabilities.


Proposed solution 2

  1. Have one new capability called "trusttext" or something.
  2. 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).
  3. When saving a text from a user, modules can call a function on the text ("hello world") and insert special tags if the current user is trusted, something like this:
  $text = mark_text_as_trusted($text);
hello
  1. When showing the text with format_text(), each text is checked for these tags surrounding the whole text.
  2. If found then cleaning is not done, and those tags are removed before output.
  3. If not found then cleaning is done fully, then output.