Phabricator/Security

By default, tasks, files, and other objects in Wikimedia Phabriucator 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 in MediaWiki software, and some of these are related to general sensitive Operations 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

 * none - Applies no transform, preserving the existing policy, project, and other metadata properties of a task.
 * Security or Sensitive Bug - Ensures the Security project is included, enforces the Security project + author edit/view policy
 * Private Issue - Ensures the Security project is included, enforces the Security project for edit and view policy.

When to Select a Security Option

 * none - This is the default under which no adjustments will be made.
 * Security or Sensitive Bug - This is appropriate for any bugs or security issues related to Wikimedia software.
 * Private Issue - This is appropriate for confidential issues within Wikimedia Phabricator or any task the author is unsure of for disclosure.

Users CCed in private tasks should be able to access them

 * Upstream has addressed this issue  in discussion and has made their thoughts known.
 * While Bugzilla had no concept of Policy or ACL outside of issue metadata, Phabricator does.
 * CC users have never been restricted from viewing or accessing a task if they are allowed via view policy.
 * CC users have been getting emails for tasks they cannot view (an information leak issue). This has caused a lot of confusion.
 * It is the intention of upstream to sanitize sensitive task emails to CC users who are not allowed via policy.
 * It is the intention of upstream to make view Policy permissions a hard limit which includes not allowing CC to violate the view policy.

Prevent that private information is leaked via Herald notifications

 * The existing Security transforms are performed by the Herald events system.
 * Herald only checks the Security of a task "pre flight" so user rules can currently match on tasks they should not before sanitization.
 * mmodell (the Security extension creator) has proposed changing to using Events which fire pre-herald as the fix to this.
 * Currently, Herald is disabled for this reason. We cannot reasonably prevent information disclosure while using Herald as our mechanism.
 * Events are largely an internal interface to Phabricator, and while it is possible that they may change, their stability is fairly well established.

Cannot view Bugzilla migrated private/security tasks I am author/reporter of

 * The migration from Bugzilla purged non-Security members for the Policy of imported issues via the Security-Bug transform.
 * This was not an intentional policy purge, the testing of sensitive issues was very limited due to security concerns in Labs.
 * The intention is to set the policy state of all issues that originated in Bugzilla to an equivalent policy in Phabricator.
 * This modification is currently pending for discussion to determine the extent of policy modification desired.
 * This is in no way related to the current state of filing secure tasks in Phabricator and is only an undesirable migration outcome.

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

 * The migration team intended to finish the Events and Non-Herald dependent Security transform behavior prior to migration, but this did not happen.
 * Currently the transform behavior still depends on Herald, but was sorely missing documentation as a result of the intended changes.
 * Hopefully, this page addresses this.

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.
 * Some other mechanism for acquiring the desired policy settings for tasks will need to be figured out.

Proposed Updates to Process

 * 1) When a "security-bug" is filed, only do policy transform to ensure members of the Security group/author have access and to ensure neither public nor all users is included.
 * 2) * Authors of tasks have all original reporting information anyway so limiting their scope and visibility is pointless.
 * 3) * 'Public' and 'users' are special values within Phabricator that denote an absence of enforceable policy; excluding them is sane.
 * 4) * It is reasonable to assume that if a task is marked as security-bug, it cannot be open for public or all users.
 * 5) Change current Herald application mechanism over to Events.
 * 6) * Herald leaves lots of undesirable artifacts on issues (set none to none, etc).
 * 7) * Using Herald to secure Herald actions from users has proven to be complex and unintuitive.
 * 8) * Events are straight forward and would (in theory) set policy pre-Herald allowing normal interaction.
 * 9) We could (in theory) set up the transform to add any new CC users to the view ACL automatically for security-bug issues.
 * 10) * Assuming this is an appropriate level of trust for users who are given view, to effectively modify the view ACL themselves.
 * 11) * This is entirely untested but the idea is not too different from the Author special case
 * 12) More actively define groupings of users based on roles for Security association rather than specific users.
 * 13) * Part of the reason adding CC users to the view ACL is cumbersome is the lack of user groupings by role.
 * 14) * Moving towards grouping users by trust and role such as operations, legal, and active NDA will make this process sane.