Plastic SCM Security guide

The Plastic SCM security system is designed with the following goals in mind:

• Provide a mechanism to control access to repositories and restrict certain operations. A large number of companies mandate the assignment of different permissions to different projects, users and groups in order to efficiently restrict access and prevent sensitive data from being read or modified by unauthorized personnel.
• Enforce policies and best practices for both development and deployment. Sometimes it is not about restricting access (think about small agile teams where trust is everything) but about enforcing best practices and prevent mistakes. This is the main reason why many development groups restrict the access to the main development line (the br:/main branch in Plastic parlance) so that only integrators can make modifications to it.

In Plastic every single object has an associated Access Control List (ACL) which makes it very simple to customize access and overall security.

The goal of this guide is to explain how the Plastic SCM security system works by going through practical case studies and examples.

The first step to securing your Plastic SCM server is to close any open doors. By default Plastic SCM gets installed with all the open doors. By default, when Plastic SCM is first installed the default security set up is to leave all entirely open. This means that any user authenticated by the system will be granted full access.

Since only recognized users can log in by default, when a non-authenticated user tries to connect to the Plastic SCM server an error message is displayed like the example below:

And the reason is that mike is not authenticated in the Plastic SCM server:

But, as we've said before, by default any other authenticated user can do almost everything because the ALL USERS group is the owner of the repositories server (repserver):

If your environment requires security restrictions, whether they are to prevent unwanted access or enforce certain development policies, you should consider the following helpful hints:

• Consider changing the permissions to the repository server as the first step in setting up a security policy. Changing the permissions to the top level element in the security hierarchy will ensure that all the rest of the objects get secured.
• Define which users and groups will have access to the Plastic SCM server and then give them the right level of access to the repository server. Later on you can customize specific privileges to repositories, branches and even items, if required.

These general rules can be implemented by doing the following steps:

1. Set up an administrator user and grant it full access.
2. Remove the ALL USERS group from the top of the hierarchy.
3. Carefully define the users and groups and their permissions.

Refer to the following chapters to get all the information you will need to secure Plastic SCM.

As we have seen previously, to start securing the Plastic SCM repositories server (repserver) you must set up an administrator user who will be the owner of the repserver. To do that, open the Permissions for the repserver window from the Repositories view in the Plastic SCM GUI:

In the Permissions for the repserver window you'll see that by default the group ALL USERS is the owner of the repositories server. What we need is to set up a repserver administrator user and remove that group. So click the Change button and in the new window look for the user you want to be the administrator user and click OK:

By selecting maria as the repserver administrator, she has now become the owner:

But since the group ALL USERS still has all the permissions granted, all users will inherit all of these permissions by default so it is necessary to remove the ALL USERS group. But before you can remove the ALL USERS group, a user or group must be added and all the permissions must be granted.

To do that, click the Add button and select a user or group. We're going to designate the user maria as the owner and administrator:

Now click OK and, by default, all permissions will automatically be granted to the user maria. You can now remove the group ALL USERS and maria will remain as the only authenticated user in the Plastic SCM system:

You can now click OK to save this change and close the window.

Description:

One of the operations a Plastic SCM user is able to execute is deleting a repository.

Security policy to enforce:

Any user belonging to the Consultants group will not be allowed to delete a repository.

To enforce this security policy, the administrator will do the following:

• Add the group Consultants.
• Deny the remove repository (rmrepository) permission to this group at the repserver level to prevent these users from deleting a repository.

How to configure the security policy:

1. The administrator opens the Permissions for repserver window:
   

2. The administrator will select the Consultants group and deny the remove repository (rmrepository) permission and then click OK to save this change.
   

Check the configuration:

If any user in the Consultants group tries to delete a repository then the following error message will be displayed:

If the security policy is that users in every group cannot delete repositories:

• Select the ALL USERS group.
• Once added to the Users and groups list select it and double click the Allow All button to disable all the permissions but allow (enable) the view and read permissions.
• To prevent any user from removing repositories then deny the rmrepository permission:

Description:

Consider a company that has several projects in development. Each project is run by a development group that is specifically assigned a given repository to work with.

Each repository can be thought of as a project in which certain functionality is implemented. So, at any given moment in time, a second development group may require read access to a repository not directly assigned to them. In this situation the second development group considers the repository a subproduct (a dependency or a library) for their project.

Security policy to enforce:

Grant a development group read access to a repository that they are not directly assigned to:

To enforce this security policy, the administrator will do the following:

• Deny all the permissions to grp02 on the rep01.
• Grant only read and view permissions to grp02 on the rep01.

How to configure the security policy:

1. The administrator will launch the Permissions window for the rep01 from the Repositories view:
   

2. The administrator will add grp02. Then, click the Deny All button to deny every permission to grp02. And grant the read and view permissions:
   

3. The administrator will then click OK to save this new group of permissions on the rep01 repository.

Check the configuration:

Now every user belonging to the grp02 group will be able to see (read) every item in the rep01 repository. But they won't be able to perform any other operation such as rename a branch, create a label or remove a changeset.

Description:

The Testers group is made up of users that perform testing on code in order to find issues during the development cycle. Because their work is related to testing but not developing, they must have restricted access to the system source code.

Security policy to enforce:

Any member of the Testers group in the rep00 repository will not be allowed to change any item inside the sys folder in the repository.

To enforce this security policy, the administrator will do the following:

• Create a secured path related to the sys code folder in the rep00 repository.
• Deny the check in (ci) permission to the Testers group on the new secured path.

How to configure the security policy:

1. In the Repository view, the administrator will launch the Path permissions dialog:
   

2. The administrator will click the Add button to create a new secured path. In the new window, type or select the /src/sys folder, Then, click OK to save this new secured path:
   

3. Once the secured path is created, all the users and groups defined in the repserver will appear in the Users and groups list. At this point, the administrator must indicate the specific users or group that will not be able to make any change in that folder. To do this, start by clicking the Add button related to Users and groups and then select the Testers group. Click OK to add this group. Edit the permissions to the Testers group denying the check in (ci) operation. Click OK to save this permission:
   

Check the configuration:

If any user in the Testers group tries to execute a checkin operation on any item in the /src/sys folder, the following error message will be displayed:

Description:

The Testers group is made up of users that perform testing on code in order to find issues during the development cycle. Because their work is related to testing but not developing, they must have restricted access to any script directory.

Security policy to enforce:

Any member of the Testers group in the rep00 repository will not be allowed to change any item inside any script folder on the main, development and release branches.

To enforce this security policy, the administrator will do the following:

• Create a secured path related to any (relative path) script folder on the main, development and release branches in the rep00 repository.
• Deny the check in (ci) permission to the Testers group on the new secured path.

How to configure the security policy:

1. In the Repository view, the administrator will launch the Path permissions dialog:
   

2. The administrator will add a new secured and relative path associated to any script folder, check the Configure branches after creating path option and then, click OK:
   

3. In the Branches window, the administrator will select the branches that will be affected by this permission. In this example we must select the main, dev (development) and release branches:
   

4. The administrator can click OK to select the branches or, optionally, type in an identification tag for this selection and click OK to save this secured path. Then, click the Add button related to Users and groups and select the Testers group. Click OK to add this group. Edit the permissions to the Testers group by denying the check in (ci) operation and then click OK to save this permission:
   

Check the configuration:

If any Tester user tries to make a change to any item in any script path on the main or development or release branches then the following error messages will be displayed:

Description:

The project manager has defined a new rule that consists of restricting changes to items in the development branch in the rep00 repository, to certain groups.

Security policy to enforce:

Any user belonging to the Release builders group will not be allowed to modify any item on the development branch.

To enforce this security policy, the administrator will do the following:

• Create a new permission associated with the development branch in the repository rep00.
• Disable the check in (ci) permission to the Release builders group.

How to configure the security policy:

1. The administrator will launch the Permissions window for the development branch from the Branches or the Branch Explorer views:
   

2. The administrator will add the Release builders group and deny the check in (ci) permission and then click OK to save this permission:
   

Check the configuration:

So now, every time a Release builder user tries to change any item on the dev (development) branch, the following error message will be displayed:

Description:

The team has a new member. The project manager doesn't want that user to modify anything except those items under a specific path.

Security policy to enforce:

In this scenario, the user eddie won't be able to modify anything (anything under path /) except only the items under the path /src/cm.

To enforce this security policy, the administrator will do the following:

• Deny the check in (ci) permission for everything to the user eddie.
• Allow by overriding the check in (ci) permission for the path /src/cm to the user eddie.

How to configure the security policy:

1. The administrator launches the Path permissions dialog by right-clicking the required repository from the Repositories view:
   

2. The administrator selects All branches under the path /, adds the user eddie and deny the check in (ci) permission. Then, the administrator clicks Apply to save this permission:
   

3. To make sure that eddie can checkin under the path /src/cm, then the administrator clicks Add to create a new secured path. In the new window, the administrator selects or types the /src/cm. Then, he clicks OK to save this new secured path:
   

4. The administrator selects All branches under the path /src/cm, adds the user eddie and then makes sure that the Allowed ci permission is enabled, clicks override for the Denied ci permission, and keeps it empty:
   
   Because the /src/cm path overrides a denied permission, the resultant ACL cleans the permission that the override mask defines and sets the permissions for the /src/cm path.
5. Then, the administrator clicks OK to save this new configuration.

Check the configuration:

• After both denying the checkin (ci) permission under the path / and overriding the checkin (ci) permission under the path /src/cm for eddie, then he is able to checkin any change done on any item in /src/cm:
  

• After denying the checkin (ci) permission for eddie under the path /, then eddie gets the following error if he tries to checkin any change done everywhere except /src/cm:
  

• If the administrator doesn't override the checkin (ci) permission for eddie under the path /src/cm, then eddie gets the following error if he tries to checkin any change done in /src/cm:
  

Description:

In this situation you want to restrict access to the revisions stored on the release branch. You want to allow the developers to read data from that branch, but not allow them to make any changes.

Security policy to enforce:

Deny all the permissions except the read access on a branch to a group.

To enforce this security policy, the administrator will do the following:

• Disable all permissions except the view and read permissions for the developers group on the release branch.

How to configure the security policy:

1. The administrator will launch the Permissions window for the release branch from the Branches or the Branch Explorer views:
   

2. The administrator will Add the Developers group and edit their security policy by denying all the permissions except the read and view ones. Then, click OK to save the changes:
   

Check the configuration:

If a developer tries to make any change, e.g. apply a label or change a comment on the release branch, then the following error message will be displayed:

It is possible to restrict read access to certain paths so that some parts of the repository are not visible to certain users. It is useful in centralized setups where sensitive areas of the project must be protected in such a way that they can't even be seen by some project members.

Let's see how this read access restriction works with some Plastic operations:

• Update (download)
• Diff
• Merge
• Get revisions

Description:

It is possible to restrict read access to certain paths so that some parts of the repository are not visible to certain users.

Security policy to enforce:

In this scenario, the user mike won't be able to update the /scr/tools path, and any script folder in the dev and release branches.

To enforce this security policy, the administrator will do the following:

• Create a secured path related to the /src/tools path in the rep00 repository.
• Create a secured path related to any script folder in the dev and release branches in the rep00 repository.
• Deny or remove the read permission to the user mike for those paths.

How to configure the security policy:

1. In the Repository view, the administrator will launch the Path permissions dialog:
   

2. The administrator will then click the Add button to create a new secured path. In the new window, type or select the /src/tools path and then click OK to save this new secured path:
   

3. Once the secured path is created, then all the users and groups defined in the repserver will appear in the Users and groups list. At this point, the administrator must indicate the specific users or groups that will not be able to download (by doing update) and see that path. In our scenario, we'll select the user mike. Edit the permissions by denying the read operation:
   

4. The administrator will add a new secured and relative path associated to any script folder. Then, he'll check the Configure branches after creating path option, and then click OK:
   

5. In the Branches window the administrator will select the branches that will be affected by this permission. In this example we'll select the dev and release branches:
   

6. The administrator can click OK to select the branches, or optionally type in an identification tag for this selection and click OK to save this secured path. Then, select the user mike. Edit the permissions by denying the read operation and then click OK to save this permission:
   

Check the configuration:

• If the user mike tries to update (download) any script path on the dev or release branches, then mike won't be able to see those secured paths:

  

• If the user mike tries to update (download) the /src/tools path, then mike won't be able to see that secured path:

  

Description:

It is possible to restrict read access to certain paths so that some parts of the repository are not visible to certain users.

Security policy to enforce:

When running diffs, the user mike won't be able to see the changes in the /src/tools path because he doesn't have permissions to read there.

To enforce this security policy, the administrator will do the following:

• Create a secured path related to the /src/tools path in the rep00 repository.
• Deny or remove the read permission to the user mike for that path.

How to configure the security policy:

1. In the Repository view, the administrator will launch the Path permissions dialog:
   

2. The administrator will then click the Add button to create a new secured path. In the new window, type or select the /src/tools path and then click OK to save this new secured path:
   

3. Once the secured path is created, then all the users and groups defined in the repserver will appear in the Users and groups list. At this point, the administrator must indicate the specific users or groups that will not be able to diff and see that path. In our scenario, we'll select the user mike. Edit the permissions by denying the read operation:
   

4. The user maria will make some changes: one in the /scr/tools path, and another one in the /src/cm path.
   

5. Then, maria will save the changes (by doing checkin) and will run a diff:
   

Check the configuration:

If the user mike runs a diff, then he won't be able to see the changes in the /src/tools path. The diff operation will filter out the differences. If the source of the diff can't be seen, the diff won't be visible:

Description:

It is possible to restrict read access to certain paths so that some parts of the repository are not visible to certain users.

Security policy to enforce:

The user mike won't be able to merge a branch if there are changes in the /src/tools path that he can't read.

To enforce this security policy, the administrator will do the following:

• Create a secured path related to the /src/tools path in the rep00 repository.
• Deny or remove the read permission to the user mike for that path.

How to configure the security policy:

1. In the Repository view, the administrator will launch the Path permissions dialog:
   

2. The administrator will then click the Add button to create a new secured path. In the new window, type or select the /src/tools path and then click OK to save this new secured path:
   

3. Once the secured path is created, then all the users and groups defined in the repserver will appear in the Users and groups list. At this point, the administrator must indicate the specific users or groups that will not be able to merge and see that path. In our scenario, we'll select the user mike. Edit the permissions by denying the read operation:
   

4. The user maria will create two branches and make some changes: one in the /scr/tools path in the task01 branch...
   

   ...and another one in the /src/cm path in the task02 branch:

   

Check the configuration:

• The user mike refreshes the Branch Explorer and he's able to see both branches. But if he tries to merge the task01 branch, then the merge will fail and notify him that the merge can't proceed due to security restrictions. The merge is rejected because mike doesn't have the read permission for every change in the source contributor:
  

• The user mike is able to merge the task02 branch and to switch to the task01 one. But, he's not able to see the diffs of task01 branch because he doesn't have the read permission on /src/tools path:

  

Description:

It is possible to restrict read access to certain paths so that some parts of the repository are not visible to certain users.

Security policy to enforce:

The user mike won't be able to see the content of revisions under a path that he can't read.

To enforce this security policy, the administrator will do the following:

• Create a secured path related to the /src/tools path in the rep00 repository.
• Create a secured path related to any script folder in the dev and release branches in the rep00 repository.
• Deny or remove the read permission to the user mike for that path.

How to configure the security policy:

1. In the Repository view, the administrator will launch the Path permissions dialog:
   

2. The administrator will then click the Add button to create a new secured path. In the new window, type or select the /src/tools path and then click OK to save this new secured path:
   

3. Once the secured path is created, then all the users and groups defined in the repserver will appear in the Users and groups list. At this point, the administrator must indicate the specific users or groups that will not be able to download (by doing an update) and see that path. In our scenario, we'll select the user mike. Edit the permissions by denying the read operation:
   

4. The administrator will add a new secured and relative path associated to any script folder. Then, he'll check the Configure branches after creating path option, and then click OK:
   

5. In the Branches window the administrator will select the branches that will be affected by this permission. In this example, we'll select the dev and release branches:
   

6. The administrator can click OK to select the branches, or optionally type in an identification tag for this selection and click OK to save this secured path. Then, select the user mike. Edit the permissions by denying the read operation and then click OK to save this permission:
   

Check the configuration:

• The user mike won't be able to see the content of the /src/tools path in any branch:
  

• The user mike won't be able to see the content of any script folder in the dev and release branches:
  

  But, he'll be able to see the content of any script folder in any branch different from the dev and release branches:

  

• The user mike won't be able to see the content of a file in any script folder in the dev and release branches:
  

  But he'll be able to see the content of a file in any script folder in any branch different from the dev and release branches:

  

You've learned how to create a secured path with its permissions and how to assign it to users and groups. As you know, a secured path prevents users and/or groups to perform operations (change, read...) on this path.

A user could think about trying to "hack" this security rule. This way, he could get access or make changes to the secured path, for example. But we thought about it too and we can avoid it.

Let's suppose the following scenario in which the administrator performed the following actions:

• Create a secured path related to the /src/tools path in the rep00 repository.
• Deny or remove the read permission to the user mike for that path.

The user tries to rename the parent directory /src of the /src/tools secured path because he supposes he could see the content by changing the secured path name. But the following error message will be displayed:

The Plastic SCM security system detects that the permissions are different, and automatically this hacking is avoided.

August 2, 2018

June 22, 2016

May 25, 2015