Development: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 (updated with feedback and ideas from the rest)
Risk bitmask in capabilities
Add risk bitmap field to each capability. Each bit indicates presence of different risk associated with given capability.
Basic risks
- access to private personal information - ex: backups with user details, non public information in profile (hidden email), etc.
- missing XSS protection - entering of uncleaned content such as HTML with javascript or unprotected uploaded files
- dangerous global configuration changes - various settings that might render whole site unoperable, changing trust bitmaps
- some more if needed (can be added later)
Implementation
- add new LONGINT column riskbitmask to table capabilities
- define risks and assign them to capabilities in mod/xxx/db/access.php
- 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 would be minimal, icons and maybe colors indicating each risk together with description links which we need anyway. Developers would be deciding about the risks, the risk assignment would be hardcoded in access description file, no GUI needed.
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 bitmap 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 dangerous global configuration risk
- add trust checks to has_capability() and require_capability()
- add GUI
- preset trust bitmask for new users
- changing of trust bitmasks
- add field 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 bitmap 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 management code.
Note: trusttext moved to its own page at Trusttext cleaning bypass
