Make WordPress roles/capabilities more secure (edit_users related)
|Reported by:||Otto42||Owned by:|
We've discussed this before, but after some thought, I think we can do this and make it work.
Right now, the edit_users capability is the key to the kingdom. Anybody with edit_users can change their role to anything, including to something with more capabilities than they already have.
In #8770, an editable_roles filter was introduced, which allows a plugin to limit the roles that a user can change themselves too. This works for one aspect of the problem, but a) it doesn't solve the passwords problem(1), and b) it assumes that the roles are still only in one chain of command. That is to say, that all the roles have an ordering, where each role has all the capabilities of the role "below" it.
To solve these, I think we need a capability comparison system. To wit, code that implements these two rules:
- No user can change the role of another user to a role that has capabilities that the changing user does not also have.
- No user can change either the role or the password of another user who has any capability that the changing user does not also have.
For rule 1, this means that if Adam was to try to assign Bob a role, he would only be given the choice of assigning roles that have a subset of the capabilities Adam himself had.
For rule 2, if Adam was to try to change the role or the password of Bob, he would not be able to change either unless Bob already had a subset of Adam's own capabilities.
This makes the roles have a sort of definable hierarchy, where roles with lesser capabilities can be multi-faceted. I can define more than one chain of roles which are "above" each other in hierarchy, allowing me to build a tree of groups and users capable of different things.
For things like bbPress-as-a-plugin, this sort of enforcement is going to be a must-have feature.
Note 1: The "passwords problem" is that any user who can change another users password can easily change the password of somebody of "higher" rank, log in as them, and then have their capabilities. It's detectable, but in some cases, may not be so detectable. Admins who don't log in often, say.
Note 2: We also need role management in core, but that's a topic for a separate day. I'm speaking only of enforcement of a security model here for now.