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

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.