Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Hardening new Roles system

From MoodleDocs

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 1a

See talk page.

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 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).
  4. When displaying the text with format_text(), a new parameter needs to be passed to enable the trust system ($options->usetrust = true).
  5. 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.
  6. For caching, the text is stored in the final form as it is now.

Example

Storing the text

Here is the original text from the user:

  Elephant says <script>alert('hello')</script>

Here it's converted before storage:

  $text = mark_text_as_trusted($text);

For a trusted user, this will be stored as:

  ####TRUST####Elephant says <script>alert('hello')</script>

For an untrusted user, this will be stored as:

  Elephant says <script>alert('hello')</script>

Showing the text

If the tag is found then cleaning is NOT done, and that tag is removed before output.

 Elephant says <script>alert('hello')</script>

If not found then cleaning is done fully (as it is now in Moodle):

 Elephant says