Page MenuHomePhabricator

The options of the Security dropdown in Phabricator need to be clear and documented
Closed, ResolvedPublic

Description

Currently the Security dropdown has these options:

  • none
  • Security or Sensitive Bug
  • Private Issue

The scope of each option is unclear, and the implications of filing a task in one bucket or the other are unclear as well. There is no documentation in mw:Phabricator/Help.

Especially now that we are focusing on the RT migration (which might/will bring more options) we should clarify this.

PS: this came up in a chat with @csteipp.

Proposal (work in progress):

  • MediaWiki security bug. Report of a security breach in MediaWiki software, extensions, apps, elsewhere... Planned to be public after the bug has been resolved. Can View: Security , author, assigned, CCed.
  • Other private issue. Task most likely related to the Wikimedia infrastructure, triaged by the Operations team. Most likely it will remain private. Can View: SRE , author, assigned, CCed.

This is how it would look like in the task creation page:

Security None

Software security bug
Other confidential issue

NOTE:
  • the key for MediaWiki security bug is security-bug
  • the key for Other confidential issue is sensitive
  • the key for none is default

I updated phab-01 to intended versions for arc/libphutil/phab/sprint/security.

Based on patch set 3 of https://gerrit.wikimedia.org/r/#/c/183457/:

Security-Bug:

  • Creating an issue with security-bug allows the author via policy
  • Creating an issue with security-bug allows members of Security via policy
  • Modify policy with security-bug enabled to allow a specific user via policy
  • Modify policy with security-bug enabled to allow a specific group of users via policy
  • Creating an issue with security-bug associates Security project
  • Creating an issue with security-bug allows non-Security project
  • Security-bug does not allow an issue to be set to view for public or all users while enabled (yes but with big caveats for herald)
  • Security-bug does not allow an issue to set to all users for edit (yes but with caveats)
  • Setting an existing issue from none to Security-bug performs policy manipulation to make the task secure (this means not allowing public or all users) (this will not strip existing CC's programatically)
  • Creating an issue with security-bug allows CC'd users via policy (view and edit)
  • Setting an existing issue as Security-Bug associates the Security project
  • Prevents users from CCing themselves via Herald [1] (on new creation yes but not if a user tries to public an issue accidentally)

Sensitive:

  • Creating an issue via Sensitive allows the author via policy
  • Creating an issue via Sensitive allows members of the WMF-NDA group via policy
  • Creating an issue via Sensitive associates the WMF-NDA project
  • Sensitive does not allow an issue to be set to view for public while enabled (yes but with big herald caveats)
  • Sensitive does not allow an issue to set to all users for edit (yes but with big herald caveats)
  • Setting an existing issue to Sensitive performs policy manipulation to make the task secure (this means not allowing public or all users and allowing WMF-NDA and author via policy). This is caught by the herald rule so it comes with herald caveats but seems to work from testing so far.
  • Setting an existing issue as Sensitive associates the WMF-NDA project
  • Prevents users from CCing themselves via Herald [1] (on new creation yes but not if a user tries to public an issue accidentally)

Default:

  • performs no transform on new issue
  • performs no transform on issue set to none from other
  1. Prevents users from CCing themselves via Herald on a security issue someone tries to set as public (this is done via a last check herald rule for now that means regular users can CC themselves on a security issue that someone tries to set as public. The public will be rescinded but their CC will remain, and because of intended CC functionality they will have edit/view permissions all from a sneaky herald rule. This is especially strange as setting an issue for view to public allows a user who has an "always cc me herald rule" to sneak in, but setting to edit seems not to. Bug in phab?) This also creates an issue with security-bug issues where if a user has an "always cc me" rule they cannot be removed from CC as the herald processing works before the permissions are removed continually readding them. That mean a user can effectively create a herald action that makes it impossible to remove their access to a security isue as CC == policy perms. Without this we cannot enable herald for all users.

Event Timeline

Qgil claimed this task.
Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil changed Security from none to None.
Qgil added subscribers: Qgil, Aklapper, mmodell and 2 others.
Qgil removed Qgil as the assignee of this task.Dec 3 2014, 11:25 AM

@chasemp wrote https://www.mediawiki.org/wiki/Phabricator/Security#Understanding_.27Security.27_Field_Transforms -- thank you!

An edited quote:

Security or Sensitive Bug

  • Ensures the Security project is included, enforces the Security project + author edit/view policy
  • This is appropriate for any bugs or security issues related to Wikimedia software.

Private Issue

  • Ensures the Security project is included, enforces the Security project for edit and view policy.
  • This is appropriate for confidential issues within Wikimedia Phabricator or any task the author is unsure of for disclosure.

So... both private options end up in the same Security basket, seen by the same people? If this is the case, wouldn't it be better to have one private option? And have new options only when a different view-edit policy is needed (i.e. when the RT migration lands in phab).

Which are the new Security dropdown options expected to be added with the RT migration?

In T76564#809438, @Qgil wrote:

@chasemp wrote https://www.mediawiki.org/wiki/Phabricator/Security#Understanding_.27Security.27_Field_Transforms -- thank you!

An edited quote:

Security or Sensitive Bug

  • Ensures the Security project is included, enforces the Security project + author edit/view policy
  • This is appropriate for any bugs or security issues related to Wikimedia software.

Private Issue

  • Ensures the Security project is included, enforces the Security project for edit and view policy.
  • This is appropriate for confidential issues within Wikimedia Phabricator or any task the author is unsure of for disclosure.

So... both private options end up in the same Security basket, seen by the same people? If this is the case, wouldn't it be better to have one private option? And have new options only when a different view-edit policy is needed (i.e. when the RT migration lands in phab).

Which are the new Security dropdown options expected to be added with the RT migration?

There will be two drop downs post RT still. Originally planned as 3: Ops Requests, Private Issues, and Security Bug. Ops requests that are new in Phab will just be public by default, with documentation that a private ops requests should just use the generic private issue. Private Issue should be viewable by at least SRE, Security, probably Phabricator, and maybe just collapsing it into WMF-NDA. But essentially the generic is handling a few edge and legacy cases, and security bug is most directly a straight port of needed Bugzilla functionality.

Once RT is completely moved over (or at least the next idea) there will be an 'Ops Access Request' that is very different and does a host of things like creating a blocker with specific permissions to evaluate the request.

So at this moment I think it is: Private Issue, Security Bug, or None
Post first wave of RT: same
Post second wave of RT: Private Issue, Security Bug, Ops Access Request, or None

See the proposal in the description, trying to solve two problems:

  • Easier to distinguish which option is what for (and is not)
  • Provide a hint of who will see the private task.

I'm not sure about such a wide universe of people having access to the private Ops tasks, but this is of course not my call. Whatever @chasemp says in the name of Ops works for me. I'd rather keep the default small and add other groups onely when needed.

Easier to talk about on a call due to the minutia, but essentially Operations Task is not semantically correct because that isn't how operations tasks are filed. The case of Operations Access Request will be special in several ways and cannot be collapsed in. The case of Private Issue or Task is special in several ways as it is not a security task or bug and needs a wider net cast with wmf-nda that @csteipp has said cannot be allowed to access security bugs.

The three buckets are distinct in terms of enforceable behavior:

  • None
  • Security Bug
  • Private Issue (private ops requests will go here now)

The fourth is the most unique of all:

  • Operations Access Request

(but won't come into play until that is migrated -- which at this point is TBD)

Just a note to say that we will use a team meeting to discuss this until agreeing on a proposal, but not before the RT migration (next Wednesday), which is taking all our attention now.

FWIW: once this is decided, we can fairly easily add the documentation to the submission page using remarkup in the "instructions" configuration key

Thanks for the ping. I'll bring this task to our team meeting today.

See the task description with the updated proposal after our chat yesterday.

The two main use cases for a private task today are:

  • a MediaWiki security bug
  • a Wikimedia infrastructure sensitive request

Then there is a chance to receive some misc private technical issues. Instead of having three options for MediaWiki... Wikimedia... Other... we have decided to offer just two: MediaWiki security bugs (a clear scope) and all the rest (triaged by the Operations team since most of these tasks are for them anyway).

About documentation in the submission page, I actually hope we can have less text, not more, by having clear labels:

Privacy    None
           MediaWiki security bug
           Other private issue

I don't know how simple would be to change "Security" by "Privacy", but I think this concept next to the proposed alternatives is clearer, making "Security settings will override permissions and projects as needed" superfluous. I'd argue that those who understand these labels understand the description, while those not understanding the labels will not understand the description anyway (and will not touch the default "None").

Yes, mostly agreed. I'm not sure about Privacy vs. Security but it should be trivial to change the label either way. The third (not yet appearing option) would be Operations Access Request and within operations we have to solidify for sure that's how we want to handle this sort of thing incoming, but most likely those options. The text I worked out with @Aklapper awhile ago, I'm not opposed to changing it but without being able to make 'privacy/security' a link to the documentation it seems like some lead in outlining this will make implicit changes to the issue is good.

Here is one for the bikeshed, do we take security reports for extensions and such? If so maybe "Mediawiki Related Security Bug' is more inclusive?

I have changed "MediaWiki security bug" for "Software security bug" because in addition to MediaWiki and extensions we have more software where such security bugs could be found.

The third option can be discussed in the context of T84861: Migrate access-requests@ from RT to Phabricator but it looks uncontroversial in any case.

I still think that "Privacy" is clearer than "Security" but if there is no consensus we can leave it as it is for now, not blocking the main improvement in the labels of each option.

Same thing with the current description, we can leave it for now in order to close this task sooner.

If you agree on all of the above, this task is then Ready to go.

To me as a clueless reporter looking at this Phabricator UI and just wanting to report an issue to help you improve your web site:
What are criteria that allowed me realize that I should set "Other private issue"?
I've seen three people so far setting "Private issue" where that should not have happened. If you interpret "private issue" as "an issue that I have, no idea if others have it too" then we'll continue to see that use.
I'd love to have words describing what should make a task a "private issue" and use those words instead of the word "private". But my brain is not creative in the morning. "Private" is like "free": I meant software, you thought of beer. ;)

"Other confidential issues"?

"Other confidential issues" sounds good to me indeed. Thanks!

chasemp updated the task description. (Show Details)
chasemp updated the task description. (Show Details)

Merging in T518 as we are settled on this functionality:

Security-bug issues (I think meant o be named Mediawiki Related Security Bugs) will allow edit/view to all CCers. This task has the status of that functionality.

chasemp updated the task description. (Show Details)
chasemp updated the task description. (Show Details)

So, where do e.g. Parsoid security bugs should be filled under? How about e.g. Heartbleed-type of issues? This "MediaWiki security bug" makes no sense to me at all, to be honest.

I believe the security drop-down is an indication of the severity of the bug, not the project with which it is associated. So any bug that is considered "security", i.e., an exploit or vulnerability in a piece of software, be it OS, package, MediaWiki, or an extension, that the WMF is running live on its servers, and thus must remain secret until it is fixed, should be filed as a security bug.

On top of that, security bugs in MediaWiki, its extensions, and other software explicitly distributed by the WMF (as opposed to things like OSes or packages, which are simply used by the WMF, not distributed) must be extra-secret because, if disclosed, they affect any third-party that is running our software.

As for the actual difference in security policies between the two, I don't know.

Updated the text and https://www.mediawiki.org/wiki/Phabricator/Security

can someone verify and see if more is required here?

In T76564#950388, @Qgil wrote:

I have changed "MediaWiki security bug" for "Software security bug" because in addition to MediaWiki and extensions we have more software where such security bugs could be found.

Yes, "Software security bug" would be better than "MediaWiki security bug".

Quoted from https://www.mediawiki.org/wiki/Phabricator/Security

Other confidential issue - Ensures the Security project is included, enforces the Security project for edit and view policy.

It seems this is not what happens. Neither does this seem to be what should happen, though I tuned out on part of that discussion, so correct me.

The explanation for security transformation might also not match, though have not recently tested.

Quoted from https://www.mediawiki.org/wiki/Phabricator/Security

Other confidential issue - Ensures the Security project is included, enforces the Security project for edit and view policy.

It seems this is not what happens. Neither does this seem to be what should happen, though I tuned out on part of that discussion, so correct me.

agreed and fixed

These items from the description of this Task seem to not be mentioned on the wiki page, neither is their confidential counterpart:
Modify policy with security-bug enabled to allow a specific user via policy
Modify policy with security-bug enabled to allow a specific group of users via policy
Creating an issue with security-bug allows CC'd users via policy (view and edit)

This is not mentioned for the confidential option on the wiki page:
Creating an issue via Sensitive allows the author via policy

Rearranged with some more details there. Not sure how deep to go on internals but everything there seems relevant to normal usage I think.

That makes it clear for me. Thx.

The one remaining issue I see in this task is the naming of "MediaWiki security bug".

Thanks Chase for working on this, this is damn good!

Only thing I'm also wondering is if enough people understand what MediaWiki is in "MediaWiki security bug" and where Wikimedia infrastructure starts (but hard to distinguish anyway), and that infrastructure would be an "other confidential issue". But we will have to triage anyway, and we'll survive as it's not like we get dozens of security issues per day.

Krinkle removed a subscriber: Unknown Object (MLST).
chasemp claimed this task.

Marking this closed then as the description matches what I know to be reality.

Was the idea of calling it a "software security bug" rather than MediaWiki rejected? It's not clear to me.

Was the idea of calling it a "software security bug" rather than MediaWiki rejected? It's not clear to me.

AFAIK @Qgil has been updating the description with the latest consensus, which is where the config stands atm.

I also think that "Software security bug" is clearer than "MediaWiki security bug".

(Sorry for not replying before; I updated the description of this task until T76564#974187 and following edits.)

I also think that "Software security bug" is clearer than "MediaWiki security bug".

dude (124×199 px, 16 KB)