# Data Leakage Protection (DLP)

[TOC]

## Introduction

This 'dlp' directory contains prototype broker filter scripts to make P4D more suitable for the "Multi Vendor Silo" use case.  In this use case, users and groups working on the server (typically vendors of the licensed Perforce customer) shouldn't know that the other users/groups exist, and shouldn't be able to easily learn what they are doing. In this model, user names (and email addresses) are privileged information.  Also classified as sensitive information are other Helix specs like client specs, branch specs, user specs, label specs, etc.

This solution may not be "the solution" for this use case. Instead it is intended to be a useful interim solution to aid in detailed clarification of the use case requirements.

## Implementation Style

This interim solution is implemented in the form of a Helix Broker config file that references a set of broker filter scripts to implement various custom behaviors.  As an example, the custom `p4 dlp` command indicates that DLP is enabled and reports the version of the DLP package.  As an example of custom behavior to meet the use case, a `p4 users` command is rejected unless run by a user with `super` access in the Protections table.

## DLP Behaviors

Behavior changes from stock p4d:

### Stay In Your Lane

The following commands to list specs are rewritten so the last args are always '-u <you>', so you can list only your own specs:

* `p4 branches`
* `p4 clients` and its builtin alias `p4 workspaces`
* `p4 labels`
* `p4 remotes`

### Must Be Owner

The following commands to edit/output a spec only allow it if you own it:

* `p4 branch`
* `p4 client` and its builtin alias `p4 workspace`
* `p4 label`
* `p4 remote`
* `p4 user`

### Must Be Super

The following commands require super access:

* `p4 groups`
* `p4 users`

## DLP Files

The following scripts support this:

* Broker Filter script: [/p4/common/hms/dlp/broker_imply-u.pl](https://swarm.workshop.perforce.com/projects/perforce_software-hms/files/main/p4/common/hms/dlp/broker_imply-u.pl)
* Broker Filter script: [/p4/common/hms/dlp/broker_must_be_owner.pl](https://swarm.workshop.perforce.com/projects/perforce_software-hms/files/main/p4/common/hms/dlp/broker_must_be_owner.pl)
* Broker Filter script: [/p4/common/hms/dlp/broker_must_be_super.pl](https://swarm.workshop.perforce.com/projects/perforce_software-hms/files/main/p4/common/hms/dlp/broker_must_be_super.pl)
* A [broker configuration file template](https://swarm.workshop.perforce.com/projects/perforce_software-hms/files/main/p4/common/hms/dlp/p4_N.broker.cfg.t) to call the filter scripts.
* A script go generate a usable broker config file from the template, [gen_dlp_broker_cfg.sh](https://swarm.workshop.perforce.com/projects/perforce_software-hms/files/main/p4/common/hms/dlp/gen_dlp_broker_cfg.sh).

## To Do

* Think about what to do with 'p4 job' and 'p4 jobs'.
* Think about what to do with 'p4 fix' and 'p4 fixes'.
* Think about what to do with 'p4 repos'.
* Helix Swarm crashing when getting a bad `p4 groups` response may be a bug? Follow up with a job.

## Known Limitations

There are several known limitations:

* Users accessing with P4V will see unexpected errors when P4V does things on their behalf, like ask for a list of users.

* This currently does not interact well with Helix Swarm; in fact the Helix Swarm server crashes when it encounters broker-filtered responses to some commands.  Thus an exclusion for the 'swarm' user (as defined in Swarm's `config.php` file) is used.  This makes some data (such as a list of groups) accessible via Swarm that otherwise should not be visible when Swarm is used.