ReadMe.md #1

  • //
  • p4-hms/
  • dev/
  • p4/
  • common/
  • site/
  • hms/
  • dlp/
  • ReadMe.md
  • Markdown
  • View
  • Commits
  • Open Download .zip Download (3 KB)

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 P4 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 P4 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/site/hms/dlp/broker_imply-u.pl
  • Broker Filter script: /p4/common/site/hms/dlp/broker_must_be_owner.pl
  • Broker Filter script: /p4/common/site/hms/dlp/broker_must_be_super.pl
  • A broker configuration file template to call the filter scripts.
  • A script to generate a usable broker config file from the template, 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'.
  • P4 Code Review 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 P4 Code Review; in fact the P4 Code Review 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.

# 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 P4 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 P4 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/site/hms/dlp/broker_imply-u.pl](broker_imply-u.pl)
* Broker Filter script: [/p4/common/site/hms/dlp/broker_must_be_owner.pl](broker_must_be_owner.pl)
* Broker Filter script: [/p4/common/site/hms/dlp/broker_must_be_super.pl](broker_must_be_super.pl)
* A [broker configuration file template](p4_N.broker.cfg.t) to call the filter scripts.
* A script to generate a usable broker config file from the template, [gen_dlp_broker_cfg.sh](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'.
* P4 Code Review 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 P4 Code Review; in fact the P4 Code Review 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.

# Change User Description Committed
#1 33516 C. Thomas Tyler Consistency pass: fix absolute URLs, p4ms->hms renames, script/doc typos and bugs

- Convert absolute workshop.perforce.com URLs to relative paths in dlp/ReadMe.md
- Fix case-mismatch link to HMS_Product_Roadmap.md in README.md
- Rename reset_p4ms.sh -> reset_hms.sh and p4broker_p4ms_test -> p4broker_hms_test
- Fix .sh-suffix bugs: bin/hms calling global_replica_status.sh (should be no ext),
  and matching SEE ALSO / doc references for sdp_sync and global_replica_status
- Add missing scripts (gtu, hrun, irun, global_replica_status) to gen_script_man_pages.sh
- Add stub scripts: nj_help.sh, broker_njob.pl, broker_mkproj.pl, broker_jr.pl
- Remove dangling absolute symlinks HostCM/p4 and HostCM/p4d (cruft)
- Rename test/b -> test/broker_ctl.sh for clarity
- Fix real bugs: broker_imply-u.pl broken regex match, gen_dlp_broker_cfg.sh and
  gen_nj_broker_cfg.sh copy-pasted Version-file existence check, garbled comment
  in broker_must_be_owner.pl, unclosed quote in tools/gsr.sh usage(), missing 'h'
  in HMS_SystemComponents.md broker command example (^ms$ -> ^hms$)
- Fix broken sed command and incomplete sentence in HMS_Install_Notes.md and
  SDP_and_HMS_Update_Process.md
- Fix broken markdown table in HMS_Product_Roadmap.md
- Fix unclosed parenthesis, missing verb, and FKA Swarm mislabel in
  HMSDeploymentPlanning.adoc
- Standardize //streams/main/... naming in HostCM/ReadMe.md
- Numerous typo fixes across README.md, HMS_SystemComponents.md,
  SDP_and_HMS_Update_Process.md, HMS_TightShipManagement.adoc,
  HMSDeploymentPlanning.adoc, HostCM/ReadMe.md, and various scripts

Co-authored-by: Copilot <[email protected]>