Phabricator/Security

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

Preamble
Phabricator does not does not associate policy with any project labels implicitly. They have affirmed repeatedly upstream 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. 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 Security and Operations

All users are expected to have the ability to file tasks that require a high degree of discretion, but we cannot grant all users the right to adjust policy globally. In order to achieve this we have created an additional form selector on the task creation and 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 from the edit interface. 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 'Sensitive or Sensitive Bug' (where it would have been 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 policy

Private Issue - Ensures the Security project is included, enforces the Security project for edit and view policy.

When to Select a Security Transform
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 tranforms 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 trigger to fix this
 * Currently herald is disabled for this reason. We cannot reasonably prevent information disclosure while using Herald as our application mechanism.
 * Events are largely and internal interface to Phabricator, and while it is possible they 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 Security 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 has restricted policy are referenced by a long, security, 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
 * Security transform is still 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 associating implicit security with project association.
 * Some other mechanism for acquiring the desired policy settings for tasks will need to be figured out.