summaryrefslogtreecommitdiff
path: root/issues
diff options
context:
space:
mode:
authorFrederick Muriuki Muriithi2024-06-06 09:59:10 -0500
committerFrederick Muriuki Muriithi2024-06-06 09:59:10 -0500
commit551c36377de2f9bb6ece84d11debd145e11b4be0 (patch)
treea06109f666e1032b3f603123ada908994f31bdfb /issues
parentf9a4e0d1488fecb87561065bde5dd356b14b6163 (diff)
downloadgn-gemtext-551c36377de2f9bb6ece84d11debd145e11b4be0.tar.gz
Privilege Escalation: New Issue
Add an issue with notes on possible privilege escalation with the current implementation of `….create_roles` function.
Diffstat (limited to 'issues')
-rw-r--r--issues/gn-auth/problems-with-roles.gmi28
1 files changed, 28 insertions, 0 deletions
diff --git a/issues/gn-auth/problems-with-roles.gmi b/issues/gn-auth/problems-with-roles.gmi
new file mode 100644
index 0000000..cd574ae
--- /dev/null
+++ b/issues/gn-auth/problems-with-roles.gmi
@@ -0,0 +1,28 @@
+# Problem With Roles: Privilege Escalation
+
+## Tags
+
+* type: bug
+* status: open
+* priority: critical
+* assigned: fredm, zachs
+* keywords: gn-auth, authorisation, authorization, roles, privileges
+
+## Description
+
+The current implementation of `gn2.wqflask.oauth2.roles.create_role(…)` function is broken and can lead to possibly unbounded privilege escalation.
+
+What it currently does is that it fetches all the roles a user has, on all resources, regardless of type and/or ownership, then allows the user to create a role from that. As such, a user with write access to ResourceA and no write access to ResourceB could hypothetically gain write access to ResourceB, by say:
+
+* Create a new throw-away account
+* Creating a new role, that includes the write access from ResourceA
+* Assign new role to throw-away account on ResourceB
+* Do unapproved writes on ResourceB with throw-away account
+
+The implementation should instead, tie the roles to the specific resource, rather than group. This means, then, that the user cannot create a role on any resource that exceeds their access level for that resource — thus no privilege escalation is possible.
+
+### Plan of Action
+
+* Remove the `….create_action` function: raise exception when used
+* Remove the "Roles" page on the UI
+* Create a new "Roles" section on the "Resource-View" page, or a separate "Resource-Roles" page to handle the management of that resource's roles