Similar to the existing $wgOATHRequiredForGroups config variable, we would create a new config variable along the lines of $wgOATHRequiredForAddingGroups. Various privileged groups (or rights) would be added to this config variable. We would then hook into various rights-granting code within MediaWiki and, for users with bureaucrat rights/roles who do not have some form of MFA enabled, they would not be able to promote other users to the list of privileged groups or rights.
Description
Event Timeline
Perhaps this should just be 'Add functionality to disallow USERS who do not have ....' no need to tie this to only the bureaucrat named group, is there?
This task specifically addresses users with rights-granting powers (userrights) within MediaWiki. It's also part of a plan for phased 2fa-enforcement for privileged users on Wikimedia projects.
I'm not following why this check should be linked to the actor's named groups? For example stewards and staff can change rights, if they disable their own 2FA shouldn't they be prevented from making such promotions? This setting could just be a boolean, where if enabled would prevent *anyone* making a rights change to add a privileged group (already on a list) to anyone, without the need to maintain a manual list of groups that could contain a permission to add such permissions.
Is there a use case where there would be some groups that should be able to make these changes without 2FA while others shouldn't?
I think we're saying the same thing? Whether it happens via logic in the code (dynamically determining which groups with the userrights right a user belongs to) or via config (setting all groups with the userrights right), we just want to force 2fa for any user attempting an action that requires the userrights right.
Think so! I'm not objecting to the concept at all, just that there are use cases that involve more than *only* members of the named "bureaucrat" user group.
The software feature would be something like $wgOATHRequiredForAddingGroups['bureaucrat'] = [ 'interface-admin' ]; it would obviously not baked into it to only work for bureaucrats.
The use case would be bureaucrats. (On some wikis, admins can add people into some groups but they aren't sensitive.)
Note that adding people into a global group is a completely different thing at the software level.
In terms of core architecture, the nice approach would be a permission check (or something very similar to that) for adding user X to group Y. Unfortunately our entire permission system is based on action + performer + target title, there is no way to sneak in additional information. The group name could be encoded into a title but that's very hacky and fragile.
The less nice but easier thing would be to add a hook to UserGroupManager::getGroupsChangeableBy() so the list of groups a given user can add to / remove from can be changed dynamically.
Note: in Wikifunctions users in the "wikifunctions-staff" can grant/revoke a number of sensitive rights (including admin, crat and interface admin) to self only. In Wikidata, "wikidata-staff"have similar power for interface admin only. In Meta, users in local group "wmf-supportsafety" can arbitrarily change any user's user group in any wiki.
See T391632: Split privileged user groups to privileged / highly privileged about determining the list of user groups that might require higher levels of security.
Note this task is about "preventing crats without 2FA from granting user SOMEGROUP". "prevent crats from grant SOMEGROUP to users without 2FA" is a distinct thing.