Prevent Privilege Escalation: Add Assignment Restrictions for Roles and Permissions

[maliming]

Resolve #24768

Problem Description

The system has privilege escalation vulnerabilities:

1. Users with AbpIdentity.Users.Update permission can assign themselves or others roles they do not currently have
2. Users with AbpIdentity.Users.ManagePermissions or AbpIdentity.Roles.ManagePermissions can grant permissions they do not possess
3. Users can escalate privileges by modifying their own user permissions or the permissions of roles they belong to
4. There is no validation to prevent indirect privilege escalation through role or permission delegation
5. UI restrictions can be bypassed by calling APIs directly

---

Solution

This PR implements a unified privilege escalation prevention model based on a single security principle:

A user must not be able to directly or indirectly cause any user (including themselves) to obtain roles or permissions they do not already possess.

The solution consists of 3 core security mechanisms, applied uniformly to all users:

---

1. Role Assignment Restriction (Identity Module)

• Users can only assign or remove roles they currently have
  • Example: if User A has roles A and B, they can only assign or remove A and B for other users
• Users cannot add new roles to themselves (removal only)
• Users cannot assign or remove roles they do not possess
• Role updates use an incremental update pattern:
  • Only roles the current user is authorized to operate on are added or removed
  • All other roles are preserved to prevent silent or accidental removal
• All validations are enforced on the backend (UI is not a security boundary)

---

2. Permission Grant / Revoke Authorization (PermissionManagement Module)

• Users can only grant or revoke permissions they currently have (effective permissions)
• Validation applies to both:
  • Grant operations
  • Revoke operations
• Prevents privilege escalation via permission manipulation or delegation
• Backend validation is mandatory and enforced even when APIs are called directly

---

3. Incremental Permission Protection (User & Role Permissions)

• When updating user or role permissions:
  • Permissions the current user does not have are treated as non-editable
  • Non-editable permissions are preserved as-is during updates
• UI marks permissions with IsEditable = false when the user lacks authority
• Backend enforces the same rules to prevent API bypass
• Prevents accidental or malicious removal of permissions outside the user's control

---

Admin Role Exception

• Users with the admin role can assign any role and grant/revoke any permission.

---

Security Rules Summary

Operation	Self	Other Users
Assign Roles	❌ Cannot add new roles	✅ Only roles the user currently has
Remove Roles	✅ Can remove own roles	✅ Only roles the user currently has
Grant Permissions	✅ Only permissions the user has	✅ Only permissions the user has
Revoke Permissions	✅ Only permissions the user has	✅ Only permissions the user has
Edit Non-Editable Permissions	❌ Preserved as-is	❌ Preserved as-is

Admin exception: users with the admin role can assign any role and grant/revoke any permission.

---

Scenario Comparison

Scenario	Before	After
User assigns a role they do not have to themselves	✅ Success	❌ Blocked
User assigns a higher-privileged role to others	✅ Success	❌ Blocked
User assigns one of their own roles to others	✅ Success	✅ Success
User removes one of their own roles from themselves	✅ Success	✅ Success
User grants a permission they do not have	✅ Success	❌ Blocked
User revokes a permission they do not have	✅ Success	❌ Blocked
User modifies protected permissions via API	✅ Success	❌ Blocked
User escalates privileges indirectly via delegation	✅ Success	❌ Blocked

Admin exception applies to the “After” column for users with the admin role.

---

Tests

• Added unit and integration tests to cover:
  • Role assignment restrictions
  • Permission grant/revoke restrictions
  • Self-modification protection
  • Incremental update behavior
  • API-level enforcement (bypassing UI)

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 13 comments.

[roc916]

这个逻辑似乎也不够好。拥有A角色，也不代表可以授予其他用户A角色。当拥有admin角色，应当可以授予其他用户任何角色。是否应该单独建表管理可授予的角色范围或其他更好的方案？

[maliming]

I think the admin role there shouldn't be any restrictions. I'll add this rule.