A user with seemingly basic privileges is able to obtain configuration information for various modules, notably credentials associated with the login-saml and smtp_server module. The user is able to send emails from the firstname.lastname@example.org email address using the credentials discovered.
The Okapi system implements permissions by either assigning them to users, or to modules. Any user assigned a permission is also assigned the “subPermissions” of that permission, if any exist. This leads to issues where permissions grant access to more than their name implies.
For example, the “configuration.entries.collection.get” permission is assigned as a “subPermission” to several permissions such as “ui-calendar.view” and “ui-inventory-instance.view”.
Thus, anyone granted one of those permissions is also granted the “configuration.entries.collection.get” permission. This permission gives access to the /configurations/entries endpoint. The endpoint reveals configuration details, including credentials for a SMTP relay server, as well as
the value of the keystore.privatekey.password and keystore.password variables used by the login-saml module. NCC Group was able to use these credentials and configurations to send an email from the email@example.com address. Thus, any user who has seemingly benign permissions such as ui-calendar.view, is also able to view these configuration details and send emails from that address.
Additionally, the “view_perms” permission set, which implies read-only permissions, includes permissions that allow for creating, editing, and deleting various resources as well. Permis- sions that are granted include permissions to edit and remove orders, create and delete notes, and view all permissions within the “Inventory” module.
An example is provided below to demonstrate potentially problematic permissions. Note that any permission that has subPermissions may have this issue.
1. Issue the following HTTP request, replacing TOKEN with a valid JWT token for a user on the system.
2. Note in the response that the “subPermissions”of this permission include permissions that allow users to edit, update, and create various resources.
Permissions should be carefully audited to ensure admin-like permissions do not get assigned as “subPermissions” to permissions whose names do not imply admin-like rights. For example, the “view_perms” permission set should be renamed or modified to not include permissions which grant create, edit, or delete functionality.
- Write a guidance document on best practices constructing permission sets and using module permissions to avoid escalating direct end-user permissions
- provide a couple examples of permission sets that include permissions direct permissions beyond what logically should be provided directly to the user (NCC example is one, we need a couple more)
Split into continuation story:
- walkthrough the proposal document with Tech Leads on the TL meeting
- create Jira tickets for individual teams to perform verification of permission sets in the modules they are responsible for, according to the best practices