Hardening new Roles system

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 special tags if the current user is trusted (and actively REMOVE such tags if the user is not trusted).
4. When displaying the text with format_text(), each text is checked for these tags surrounding the whole text and output is cleaned appropriately.

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:

  <div class="trusttext">Elephant says <script>alert('hello')</script></div>

For an untrusted user, this will be stored as:

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

Showing the text

If the tags are found then cleaning is NOT done, and those tags are 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