Page MenuHomePhabricator

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

Assigned To
Authored By
Tgr
Mar 19 2018, 6:16 AM
Referenced Files
None
Tokens
"Doubloon" token, awarded by RandomDSdevel."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.

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

Event Timeline

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

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.

In T190015#4445044, @MaxBioHazard wrote:

What is this task? It's restricted.

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

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

In T190015#4445044, @MaxBioHazard wrote:

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

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?

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)

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

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?

@SpeedyGonsales [[https://commons.wikimedia.org/wiki/MediaWiki:Right-hidden|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.

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.

In T190015#4508071, @APerson wrote:

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.

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.

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

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

it should be editsitejs

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

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?

@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

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

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.

Restricted Application added a subscriber: Strainu. · View Herald TranscriptFeb 10 2020, 10:52 PM
Restricted Application added a subscriber: Huji. · View Herald TranscriptOct 16 2020, 5:39 PM