[FOLIO-2582] Privilege escalation tenant admins with permissions.all to okapi.all Created: 04/May/20 Updated: 28/Feb/22 Resolved: 03/Nov/21 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Story | Priority: | P1 |
| Reporter: | Ian Hardy | Assignee: | Adam Dickmeiss |
| Resolution: | Done | Votes: | 1 |
| Labels: | platform-backlog, security, security-reviewed | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||
| Sprint: | CP: sprint 126 | ||||||||||||
| Story Points: | 5 | ||||||||||||
| Development Team: | Core: Platform | ||||||||||||
| Description |
|
If a tenant user is granted permissions.all, that user can assign his or herself okapi.all. Operators may want to give users a tenant admin, but prevent that tenant admin from gaining okapi.all. I believe stripes requires the okapi interface. If the okapi interface were not enabled on the tenant, there would be no okapi.all to grant. |
| Comments |
| Comment by Oleksii Popov [ 03/Aug/20 ] |
|
Postponed until the decision about permissions level. |
| Comment by Hongwei Ji [ 03/Aug/20 ] |
|
Maybe we can separate Okapi interface to at least two: one less privileged to be used by Stripes, and the other one used by supertenant to manage tenants and modules? |
| Comment by Craig McNally [ 16/Jul/21 ] |
|
Jakub Skoczen Adam Dickmeiss The security team would like an update on the status of this... It's marked as a P2, but hasn't moved in a long time. Is this something that's going to be scheduled to be worked on anytime soon? Are there blockers? etc. |
| Comment by Craig McNally [ 16/Jul/21 ] |
|
Jakub Skoczen Adam Dickmeiss The security team would like an update on the status of this... It's marked as a P2, but hasn't moved in a long time. Is this something that's going to be scheduled to be worked on anytime soon? Are there blockers? etc. |
| Comment by Craig McNally [ 14/Oct/21 ] |
|
Discussed with CP team and bumped to P1... This one is dangerous. There could be some overlap with discussions around system/tenant-level users... |
| Comment by Adam Dickmeiss [ 14/Oct/21 ] |
|
Perhaps this could be achieved by a desired permission "permissions.grant.extra" or a separate end-point. This permission would only be handed out to the supertenant This permission would not be given to the Stripes super user. All users (that do not have permissions.grant.extra) would not be able to offer permissions to others that they don't own themselves. The stripes super user should also only get okapi.readonly (not okapi.all so that mod-authtoken can be disabled - for example or worse) mod-permissions would require a change where it rejects adding permissions to a user that is not already owned by the user performing the operation. *: supertenant is an unfortunate naming convention. In some cases it means the tenant that is used when nothing is specified (default tenant) and in other cases, the tenant user that has all permissions. |
| Comment by Adam Dickmeiss [ 25/Oct/21 ] |
|
The above idea is manifested in
|