Phabricator/Security

By default, tasks, files, and other objects in Wikimedia Phabricator are publicly visible (for anonymous users as well), and editable by all registered users. However, sometimes there are reasons to keep some information private. This document explains how private information is handled in https://phabricator.wikimedia.org/.

See also Phabricator/Permissions.

Requirements
Tasks regarding sensitive topics need to be filed in Phabricator. Some of these are related to security bugs, and some of these are related to general sensitive work.

Preamble
Phabricator does not associate policy with any project labels implicitly. Upstream Phabricator developers have affirmed repeatedly that to do so is not in their plan, and it is not intended functionality. The task-centric interface means that policies are explicitly associated with tasks themselves instead. Each task has an "edit" and a "view" policy. The right to adjust policies on tasks is global. In order to grant that right, it has to be granted for all tasks. Because the right to adjust task policy is global it has been limited to members of the Security and Operations projects.

All users are expected to have the ability to file tasks that require a high degree of discretion, but Wikimedia cannot grant all users the right to adjust policy globally. In order to achieve this, we have created an additional 'Security' drop down field in the task creation form and the task edit interface. This 'Security' drop down allows users to select a transform on a task that appropriately adjusts the viewability/editability without needing global policy permission. This drop down is a transform which sets the appropriate policies, includes relevant projects, and sanitizes the issue if necessary to prevent further disclosure. At this time, the transform is applied as a custom Herald action whenever an issue is saved after editing. To allow for converting existing issues and filing new ones, in a secure state, the transform must be applied any time the drop down is active. The effect of this is that, any time the drop down is active, the basic policy template will be enforced. Changing the 'Security' selector from 'Security or Sensitive Bug' (where it is limited to a known good state for policy) to 'none' does not change the policy on the issue, but it does allow the policy on an issue to be changed. If the determination is made by Security that additional resources are needed after initial filing, this is simple to adjust to allow specific groups or users within Phabricator.

Understanding 'Security' Field Transforms
The latest complete run through of the Security field drop down can be seen in T76564
 * None
 * Applies no transform
 * Preserves the existing policy, project, and other metadata properties of a task.
 * Mediawiki security bug
 * Ensures the Security project is included
 * Ensures the Security project association
 * Allow author to edit/view
 * Allow any subscriber to edit/view (This is very custom behavior that works only for this setting)
 * Allows adhoc additions to policy (users or groups)
 * Will prevent accidental "public" or "all users" settings
 * Other confidential issue
 * Ensures the WMF-NDA project association
 * Enforces the WMF-NDA project for edit and view policy.
 * Allow author to edit/view

When to Select a Security Option

 * None - This is the default under which no adjustments will be made.
 * Mediawiki security bug- This is appropriate for any bugs or security issues related to MediaWiki or other Wikimedia software.
 * Other confidential issue- This is appropriate for confidential issues within Wikimedia Phabricator, Operations, or any task the author is unsure of for disclosure.

Valid Security States for Tasks

 * De standard Opgave politikker can SES AF Offentligheden og redigeres of all users (Registrerede users)
 * Non-registered users cannot manage resources within the Phabricator ecosystem as they do not have an identify to tie audit or actions back to. Public is not a valid edit policy setting in Phabricator.
 * Issues that may have policy different from the default: Operations issues that need to be restricted to edit (and possibly view) for WMF-NDA, security issues that need to be restricted to a special group of users, and other issues of a sensitive nature. This list is not complete.  There will be instances where a particular task or project is more sensitive for a period of time.

How to Lower the Security of a Task
To make an access restricted task entirely public again, a user who has permissions to modify the task's policy has to edit the task: Set 'Visible to' to 'Public (No Login Required)', set 'Editable by' to 'All Users', set 'Security' to none, and potentially remove projects like 'WMF-NDA' and/or 'Security' if appropriate. Obviously such an action should only be taken for good reasons (e.g. on a security task that has been made public in the meantime).

Prevent that private information is leaked via Herald notifications

 * The existing Security transforms are performed by native event system and Herald.
 * Herald only checks the Security of a task "pre flight" so user rules can currently match on tasks they should not before sanitization.
 * A requirement for the "security" field is that it prevents accidental disclosure. When someone tries to set a task to public, while security-bug is enabled, it should not be possible.
 * Currently, Herald is disabled for this reason. We cannot reasonably prevent information disclosure while using Herald as our mechanism.
 * Current requirement not met to enable Herald is "Prevents users from CCing themselves via Herald [1] (on new creation yes but not if a user tries to public an issue accidentally)".  See more details in T76564

Thumbnail images of file attachments in an access restricted Phab task are accessible to anybody when knowing URL

 * All files are protected by Phabricator policy for their landing page.
 * Originally, Phabricator relied solely on the secret hash / unknowable URL mechanism that is used in various web applications (Facebook, Dropbox, etc)
 * Wikimedia requested that URL's for attachments be not just unknowable but also inaccessible (Thus a session token is requested for direct access)
 * The security audit performed by upstream and Wikimedia (at the time) determined that thumbnails were not a desirable or necessary inclusion.
 * Thumbnails for files which have restricted policy are referenced by a long, secured, unknowable hash that only a user who already has access to the file can reveal
 * Upstream maintains there is no demonstrable disclosure vulnerability regarding thumbnails.

A direct way to submit a security report as a private task

 * Currently the intention for a few specific projects related to Operations is to route certain emails as bot created tasks from anonymous senders.
 * The security transform is applied via the existing and known mechanisms outlined above (using the auxiliary field via task creation with Conduit).
 * There is no way to set policy on a task via email.
 * There is no way to set policy on a task via project association.

Process to request a private project

 * Upstream has declined implicit security behavior with project association.
 * In the short term, if a team really needs private tasks for a project, we have to enable this with another option in the Security dropdown.
 * In the mid term, we will wait until upstream implements Spaces