[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:
Relates
relates to FOLIO-2280 tenant superuser granted excessive ok... Closed
relates to MODPERMS-157 Check assignment permissions for oper... Closed
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 MODPERMS-157 Closed .. Which is now in code review. Please look at it if you have questions or concerns.

Generated at Thu Feb 08 23:21:43 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.