[wp-trac] [WordPress Trac] #14986: Make WordPress roles/capabilities more secure (edit_users related)

[WordPress Trac]

#14986: Make WordPress roles/capabilities more secure (edit_users related)
-----------------------------+----------------------------------------------
 Reporter:  Otto42           |       Owner:                 
     Type:  enhancement      |      Status:  new            
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Role/Capability  |     Version:                 
 Severity:  normal           |    Keywords:                 
-----------------------------+----------------------------------------------
 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.

 Back in #6908 and #6014, this was thought about in terms of the old user
 levels system, which of course shouldn't be used and makes no sense.

 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:

 1. No user can change the role of another user to a role that has
 capabilities that the changing user does not also have.

 2. 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14986>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software