Create separate user group for editing sitewide CSS/JavaScript that does not include administrators by default
Closed, ResolvedPublic

Tokens
"Like" token, awarded by matej_suchanek."Like" token, awarded by ToBeFree."Like" token, awarded by TerraCodes."Like" token, awarded by Liuxinyu970226."Like" token, awarded by chasemp."Love" token, awarded by MichaelSchoenitzer."Like" token, awarded by Harej."Like" token, awarded by Smalyshev."Evil Spooky Haunted Tree" token, awarded by Krenair."Like" token, awarded by Pcoombe."Love" token, awarded by Jdlrobson."Love" token, awarded by Bawolff."Barnstar" token, awarded by Amire80."Yellow Medal" token, awarded by matmarex."Yellow Medal" token, awarded by daniel."Like" token, awarded by MusikAnimal.
Assigned To
Authored By
Tgr, Mar 19 2018

Description

Currently, MediaWiki administrators (members of the sysop user group) have the ability to edit Javascript pages: site-wide JS such as MediaWiki:Vector.js, MediaWiki:Gadget-*.js pages (used by the Gadgets extension, can be configured to load by default) and JS subpages of another user (including User:<name>/global.js, used by the GlobalCssJs extension). Thus an attacker who compromises an admin account (on some wikis, even a less privileged account such as templateeditor on hewiki) can deploy malicious Javascript to all visitors.

The ability of wiki communities to shape wikis to their liking by deploying custom Javascript is an important tool for increasing power user productivity and empowering communities to solve their problems; as such, it is desirable even with this risk. The way access to this right is currently given is suboptimal though:

  • Most administrators have no Javascript editing skills, and as such there is very little benefit in them having that right. (Maybe faster revert time in case of an attack, but even that is highly questionable.)
  • Administrators who lack computer skills not only don't need Javascript editing abilities but are extra dangerous attack vectors as they often have weaker password and antivirus practices, don't keep their systems up to date etc.
  • With Javascript editing being just one of the many rights administrators have, most communities do not fully understand its dangers and are not sufficiently careful about assigning it. E.g. relatively low-trust user groups sometimes get (that resulted in T189665 recently), no one is worried about long-inactive admins retaining their privileges, there is very little oversight of small wikis with few active admins etc.

The obvious solution for this is to split Javascript editing into a separate, dedicated user group, take away the right from all other user groups (sysop, interface-editor/engineer/templateeditor on some wikis), clearly document the risks of handing out that user group, and set higher expectations for membership (e.g. use of two-factor authentication). There is some paranoia around this issue (some people an attempt to revive Superprotect behind anything that changes Javascript editing workflows) but it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities. Local bureaucrats would be able to add and remove users, and current admins (or interface editors where that right exists) could be grandfathered in if they want to.


Patches:

(Draft) community consultation page: User:Tgr/Create separate user group for editing sitewide CSS/JS
(Draft) user group info page: User:Tgr/Technical_administrator

Affected Wikimedia user groups:

  • sysop
  • user (donatewiki, foundationwiki)
  • securepoll (officewiki)
  • electcomm/staffsupport/electionadmin (votewiki)
  • centralnoticeadmin (metawiki, testwiki)
  • botadmin (frwiktionary, mlwiki, mlwikisource, mlwiktionary)
  • engineer (ruwiki)
  • interface-editor (azbwiki, ckbwiki, elwiktionary, hewiki, huwiki, jawiki, pswiki, ptwiki, trwiki, urwiki)
  • templateeditor (fawiki, rowiki)
  • translator (incubatorwiki)
  • wikidata-staff (wikidata)

Sitewide CSS/JS editing not covered by the patch:

Related issues:

Follow-ups:

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

I don't know why you think this is such a big problem

https://meta.wikimedia.org/wiki/Creation_of_separate_user_group_for_editing_sitewide_CSS/JS#How_you_can_help

Also, please make sure your wiki has some documentation and election process for the new group past the migration period. Again, this could be as simple as asking newly elected administrators whether they also want to be technical administrators and whether they are familiar with Javascript and basic security practices. In any case, it is recommended to make the bar for technical admins at least as high as for admins (in terms of trust and user behavior), and maybe even higher (see the user group page for more advice).

If you deem it necessary, just grant them both groups?

I just checked this page and noticed many wikis are not at all informed.

@Bodhisattwa: Feel free to make that list more complete in order to fix this problem.

Johan added a comment.Jul 10 2018, 1:55 PM

For what it's worth, it was also included in Tech News (which is how the technical community communicates most technical changes to the wikis), in the issue that went out yesterday.

Teles added a subscriber: Teles.Jul 10 2018, 6:47 PM

The main problem raised is security and risk for compromising an administrators account. Y not make 2FA compulsory for administrators account. You can't restrict from the fact that administrators are trusted users from the community. And community votes for an appointment of an Administrator. Frankly speaking I don't find this as a concrete solution .Is there any indication that these so called 'engineer/etc' are secured from compromising? . Some Administrators help users in installing user scripts as they have limited knowledge, this was like a plus point. Some wikis have an user group like eliminator which can delete pages etc, so after this change it will be like those. No mediawiki namespace edits than it's very hard time for small wikis to progress in technical stuff. Whereas this request is like just addition of new user group in name of security, whereas no actual solutions of security.
Well waiting for some user that can clear my mind that how secure this new user group will be.

Thanking you.

Reedy added a comment.EditedJul 15 2018, 5:16 PM

The main problem raised is security and risk for compromising an administrators account. Y not make 2FA compulsory for administrators account. You can't restrict from the fact that administrators are trusted users from the community. And community votes for an appointment of an Administrator. Frankly speaking I don't find this as a concrete solution .Is there any indication that these so called 'engineer/etc' are secured from compromising? . Some Administrators help users in installing user scripts as they have limited knowledge, this was like a plus point. Some wikis have an user group like eliminator which can delete pages etc, so after this change it will be like those. No mediawiki namespace edits than it's very hard time for small wikis to progress in technical stuff. Whereas this request is like just addition of new user group in name of security, whereas no actual solutions of security.
Well waiting for some user that can clear my mind that how secure this new user group will be.

Thanking you.

If you read the thread you would see the small wiki thing is a non issue. If they want to grant both groups they can

Making 2FA compulsory is harder. What if people don’t have an appropriate device to be able to use? Not everyone has a smart phone.

Plus the social challenges of when people lose/break devices and then struggle to prove its their account

The point is to reduce the attack surface. Many people have access to tools they don’t need, or don’t know how to use

I just want to ask:

Is this group must be linked with the sysop usergroup or not? (i.e. you must be in the sysop group before you can be the techadmin)

Per this discussion:
https://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88/%E6%96%B9%E9%92%88#%E4%B8%89%E3%80%81%E5%80%99%E9%81%B8%E4%BA%BA/%E7%94%B3%E8%AB%8B%E8%80%85%E8%B3%87%E6%AD%B7%E8%A6%81%E6%B1%82

no, mediawiki doesn't have restrictions like that on groups. you don't need to be a sysop to be a bureaucrat and you won't need to be an sysop to be a techadmin

ToBeFree added a subscriber: ToBeFree.
Tgr added a subscriber: Ajraddatz.Jul 18 2018, 11:15 AM

Some reflections, a bit over halfway into the consultation:

  • "interface admmin" is a better name than "technical admin" (props @Ajraddatz) - it still expresses that this is a powerful permission, but is more clear about what it does. I'll probably go with that.
  • Several people remarked that two weeks is a bit short for local communities to agree on the required process. Also we need an announcement that explains to communities what they need to do without requiring them to read through the rather verbose consultation page (which needs to be translated). So I'm thinking the timeline should be: consultation ends on the 23rd, announcement is sent to translators; announcement is published and first set of patches (creating the new user group and bureaucrat access to it but not touching existing ones) are merged on the 30th; rest of patches (removing access from old groups) are merged on the 27th of August.
  • I'm leaning towards not giving bureaucrats the right to create/remove interfaceadmin by default, as smallish wikis with just a few non-tech-savvy bureaucrats might not be able (or willing) to handle it well (the same considerations about being a target of hackers that applies to admins prior to this change applies to bureaucrats as well). Local communities can still decide that they want their bureaucrats to manage interface admins, this would just be the default. Feedback: https://meta.wikimedia.org/wiki/Talk:Creation_of_separate_user_group_for_editing_sitewide_CSS/JS#Making_assigning_of_techadmin_membership_central_by_default?

@Tgr if communities need to opt-in to enable this of their bureaucrats the project level RfCs may take some time (a month is not unusual for a project like enwiki) - as the final specification for what access is being removed from sysop, and which access is being included by default in local-interfaceadmin ?

FDMS added a subscriber: FDMS.Jul 21 2018, 7:57 AM
Epine added a subscriber: Epine.Jul 22 2018, 12:51 PM

In my opinion, the removal of the edituserjss etc. rights from the sysop group should be stalled, until T200176 is resolved.

What is this task? It's restricted.

What is this task? It's restricted.

Wouldn't disclosing it defeat the point of it being restricted?

So, how long it will take?

I think the migration period of 1 month is too short, you need much more time to adapt the policies in larger wikis. I think thee transition period should be at least two months long

What is this task? It's restricted.

Wouldn't disclosing it defeat the point of it being restricted?

If this is just some obvious consequence of changing the permission balance instead of a real, effective security problem, I think restricting the task does more harm than good. It prevents users from giving input how these issues should be handled. Such tasks have to be resolved before this change is deployed either way, so there's not harm in having people be aware of possible problems for now. If such issues aren't fixed before deploying, people will get the idea how to exploit them within weeks either way, since issues of that type are generally quite obvious.

Change 421122 merged by jenkins-bot:
[operations/mediawiki-config@master] Add interface-admin to privileged groups

https://gerrit.wikimedia.org/r/421122

Change 421123 merged by jenkins-bot:
[operations/mediawiki-config@master] Temporarily preserve sysops' JS editing ability

https://gerrit.wikimedia.org/r/421123

Change 421121 merged by jenkins-bot:
[mediawiki/core@master] Segregate right to edit sitewide CSS/JS

https://gerrit.wikimedia.org/r/421121

Change 448168 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@wmf/1.32.0-wmf.14] Segregate right to edit sitewide CSS/JS

https://gerrit.wikimedia.org/r/448168

Change 449153 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@wmf/1.32.0-wmf.13] Segregate right to edit sitewide CSS/JS

https://gerrit.wikimedia.org/r/449153

Change 448168 merged by jenkins-bot:
[mediawiki/core@wmf/1.32.0-wmf.14] Segregate right to edit sitewide CSS/JS

https://gerrit.wikimedia.org/r/448168

Change 449153 merged by jenkins-bot:
[mediawiki/core@wmf/1.32.0-wmf.13] Segregate right to edit sitewide CSS/JS

https://gerrit.wikimedia.org/r/449153

Xaosflux added a comment.EditedAug 5 2018, 7:29 PM

Following up on discussion from enwiki: Will local sysops's still be able to delete css/js pages if they are not also able to edit them? Specifically in relation to user css/user js pages I suspect this is going to increase the number of users seeking access. Would it be difficult to allow admins to continue to be able to delete? I'm guessing same problem will occur for oversighting these pages? That is if an OS is not also an interface admin will they be unable to perform oversight operations on these pages?

Followup #2: Will global renamer's that are not local interface admins still be able to move user .js/.css subpages? If not, how will these fail?

FDMS added a comment.Aug 5 2018, 8:11 PM

Followup #2: Will global renamer's that are not local interface admins still be able to move user .js/.css subpages? If not, how will these fail?

The answer seems to be yes (@Ajraddatz at #Page moves):

Global renaming bypasses any local restrictions that would prevent the action or subsequent actions from being completed (i.e. if a global renamer was locally blocked on the wiki, if the page was fully protected, etc)

Tgr added a comment.Aug 5 2018, 9:00 PM

Global renaming bypasses any local restrictions

Local page move with subpages doesn't though, so keep that in mind.

Will local sysops's still be able to delete css/js pages if they are not also able to edit them?

That would be desirable for multiple reasons, I'm not sure how it could be implemented in a safe way though.

I'm guessing same problem will occur for oversighting these pages?

Oversight does not require edit rights. Of course, someone does need to edit the page first.

@Tgr agree it could be desirable - please correct me if I'm wrong but after this change this scenario is created:

1: Any editor can create a page at User:user/*.[js|css] (which can contain pretty much any text)
2: This content can only be deleted by someone that is both a sysop and an interface admin

This may drive the number of interface admins communities need up, as there will be a content management need

SpeedyGonsales added a subscriber: SpeedyGonsales.EditedAug 7 2018, 4:19 PM

Hi, this is broken on (at least) hr.wp. I have appropriate right, which can be checked:

https://hr.wikipedia.org/wiki/Posebno:Suradnici/interface-admin

But when I go to:

https://hr.wikipedia.org/wiki/Posebno:Dodaci (= https://hr.wikipedia.org/wiki/Special:Gadgets)

I get following text:

"Zahtijeva ⧼right-hidden⧽ pravo."

which translates to:

"Needs ⧼right-hidden⧽ right."

Deploying broken changes, QA?

Tgr added a comment.Aug 7 2018, 4:37 PM

@SpeedyGonsales right-hidden is/was a Commons hack to prevent a gadget from being used by anyone. Apparently whoever ported the gadget didn't bother to port the message as well. IIRC these days ResourceLoader has a hidden option so the hack is not needed anymore.
Anyway, this has nothing to do with editing, permissions shown on Special:Gadgets are for enabling gadgets.

To clarify, using rights=hidden on https://hr.wikipedia.org/wiki/MediaWiki:Gadgets-definition for this gadget means that you have to have the hidden right to enable it in your preferences. It does not affect the rights required to edit it.

Because no one has this right (because it does not exist), no one can enable the gadget, so it is effectively hidden from everyone. This is used for some libraries used by other gadgets that don't do anything by themself. Normally you'd use e.g. rights=block on a gadget that provides improvements to the block form, so that it would not show up in preferences for people who can't use it.

matmarex added a comment.EditedAug 7 2018, 5:55 PM

IIRC these days ResourceLoader has a hidden option so the hack is not needed anymore.

This is correct (although it's a Gadgets extension feature, not in ResourceLoader). It was implemented in 2016 (T33150).

@SpeedyGonsales So, to avoid the broken text on https://hr.wikipedia.org/wiki/Special:Gadgets, you can replace rights=hidden on https://hr.wikipedia.org/wiki/MediaWiki:Gadgets-definition with just hidden. There are several gadgets using this on https://en.wikipedia.org/wiki/MediaWiki:Gadgets-definition, if you need to look at an example.

Hi Tgr and matmarex,

you are both right. There were actually two problems with Gadget definition page:

  • rights=hidden and
  • having scriptname|scriptname.js[|scriptname.css|otherscript.js|...] syntax, scriptname cannot contain full set of UTF-8 characters, only ASCII.

First problem obscured second, thanks to Tgr I solved second, will now do also first.

Thank you both, regards!

Change 451076 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Enable TemplateStyles everywhere

https://gerrit.wikimedia.org/r/451076

Will the configuration changes to enable this (i.e. the user group changes) be on the deployment train for 1.32.0-wmf.18?

@APerson Can you clarify what you mean? The new user group interface-admin already exists on the wikis and users can be added to it by bureaucrats.

Does this help? https://meta.wikimedia.org/wiki/Talk:Creation_of_separate_user_group_for_editing_sitewide_CSS/JS#Next_steps

@matmarex Thanks for the link! That helps. I'm talking about the removal of mw-space editing perms from the sysop right. I assume it'll be the European mid-day SWAT, like the July 30th change? Or will the config be changed at a different time? I mostly am interested in what time on the 27th of August these other changes will happen.

Tgr added a comment.Aug 20 2018, 12:00 PM

I assume it'll be the European mid-day SWAT, like the July 30th change?

That's the plan, yes.

In my opinion, removing this permissions from the sysop group should be on hold until T200176 is resolved.

Tgr added a comment.Aug 20 2018, 1:50 PM

In my opinion, removing this permissions from the sysop group should be on hold until T200176 is resolved.

I still think that is not a huge deal, per T200176#4472162.

DMacks added a subscriber: DMacks.Aug 22 2018, 7:23 AM

There appears to be a typo in the gerrit 421125 change. In the inserted line 3675:

		|| !empty( $wgGroupPermissions[$group]['editsites'] )

it should be editsitejs

Reedy added a comment.Aug 22 2018, 9:02 AM

There appears to be a typo in the gerrit 421125 change. In the inserted line 3675:

		|| !empty( $wgGroupPermissions[$group]['editsites'] )

it should be editsitejs

Yup... Let's fix it

Change 421124 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove sitewide and user CSS/JS editing from old groups

https://gerrit.wikimedia.org/r/421124

Change 421125 merged by jenkins-bot:
[operations/mediawiki-config@master] Enforce that interface-admin is the only group that can edit non-own CSS/JS

https://gerrit.wikimedia.org/r/421125

stjn added a comment.Mon, Aug 27, 1:10 PM

Small question: while separating rights, you have granted sitewide JSON editing to sysops, but not granted it to other groups that had editinterface before (specifically, this situation is concerning RuWP’s engineers). Is this intentional in any way or could this be fixed without additional bureaucracy?

Tgr added a comment.Mon, Aug 27, 1:12 PM

@stjn that's an oversight, I'll put up a fix.

Change 455558 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/WikimediaMessages@master] Localize error message about missing interface-admin rights

https://gerrit.wikimedia.org/r/455558

Change 455561 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Add editsitejson to everyone who has editinterface

https://gerrit.wikimedia.org/r/455561

Tgr updated the task description. (Show Details)Mon, Aug 27, 2:50 PM

All the patches central to the task are live now, so I'll mark this as done. Feel free to reopen if something is not working as expected, this is causing unforeseen problems etc.

Change 455558 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@master] Localize error message about missing interface-admin rights

https://gerrit.wikimedia.org/r/455558

Epine removed a subscriber: Epine.Mon, Aug 27, 4:04 PM
Tgr closed this task as Resolved.Mon, Aug 27, 11:10 PM
Tgr claimed this task.

@Tgr see "unforseen problem" T202989 ; leaving it to you if you want this reopened or if will be otherwise handled

If anyone's keeping a record, here's another example of the need for this restriction: https://meta.miraheze.org/wiki/2018-08-26_Security_Disclosure

Usernames, IP addresses, user agents, and CSRF tokens were collected in this exploit.

Change 455561 merged by jenkins-bot:
[operations/mediawiki-config@master] Add editsitejson to everyone who has editinterface

https://gerrit.wikimedia.org/r/455561

Each user has the authority to retrieve and edit "Wikipedia language projects" and give them in different sections in other projects, and there is a problem where I do not find it good to give this power to users who have this powerful primitive, and modifying the page of this type of pages is dangerous to the user settings and I see that these The power should wait a bit and be pulled from the users who have obtained it until the problems are fixed

@Zerxo: Please do not post unrelated comments here but in different places, such as discussion forums on wikis. Thanks.