Bulletproof, Military Grade Security – Visualizing the Access Control Mechanisms of Your SCM Solution

Why visualize?

Access control is probably not the most sexy or intuitive part of any SCM (source code management) solution. However, understanding how access control mechanisms work is crucial for any enterprise that has to protect its intellectual property. What makes things tricky is that any SCM solution on the planet claims to have proper, powerful, “military grade”, “bulletproof” access controls in place. Looking at the specifics, there are huge differences that can give you a competitive business advantage (or disadvantage). A framework that helps you to visualize the differences in the fine print is a way better approach to figure out whether your security requirements are met than looking at “walls of text” or just believing generic claims.

This blog post provides such a framework. It visualizes the three fundamental dimensions of source code access mechanisms: Who (stakeholder dimension) can access  What (asset dimension) How (operation dimension). Kudos to Dharmesh Sheta who came up with the artwork.

The figure above visualizes two of the tree dimensions – the stakeholder (who) and the asset (what) dimension. The stakeholder dimension lets you specify the group of persons for which a certain access rule applies. As you can see, there are six different levels possible in this dimension:

  • Anonymous Users: Everybody, including users without any account falls into this access level. This level should be used if you like to grant access to everybody on the planet who might be interested in your assets. As this access group does not even ask for any identity of the accessing user, it can typically only be used for non modifying operations.
  • Logged-In Users: You need at least an account to be part of this level. This access level should be used if you like to grant access to anybody who got registered in your system.
  • Non-Restricted Users: This access level applies to all users that do not have a special restriction. A typical use case would be a company that allowed some contractors to register on their site (in addition to their ordinary employees). The company could mark all contractors as restricted users and assign assets that should only be available to ordinary employees to the Non-Restricted level.
  • Project-Members:  There is not a single project member access level but one for every project/product. All members of a certain project (or product) belong to this access level. This access level is typically used if you have many different roles within your project but some assets that should be visible to all project members, no matter what exact roles they have in this project. The alternative would be to manually modify every single role, which is time consuming and error prone, especially if you use project templates that only differ in certain role characteristics.
  • Role Members: There is no single role member access level but every role provide its own. Only if a user belongs to this role, the access level will apply. This level is typically used if you like to differentiate access rights within a project/product based on responsibility. One may for instance say that users belonging to the maintainer role can merge commits into the production branches whereas users belonging to the developer role can only push commits to developer branches.
  • Site Admins: This access level belongs to a group of individuals with the responsibility to maintain the entire site. They typically have permission to perform all operations to all assets in the system.
CollabNet TeamForge supports all six levels in this dimension for Git, Subversion and CVS.

When it comes to differentiating what to actually protect, there are six levels as well:

  • Branch/path based level: This is the most fine grained level and allows to only expose certain branches (Git) or paths (Subversion) instead of the entire repository.
While most solutions claim to support this level, please carefully read the fine print. In   most cases, branch based restrictions can only apply to modifying operations (like pushing commits to a certain branch), whereas read based operations (like restricting read access  to some branches) cannot be enforced. To the best of our knowledge, read based branch per-  missions for Git only exist in Gerrit based implementations.
  • Repository level: This is the standard level that restricts access to a certain repository.
  • Project/product level: If access permissions should apply to all repositories within a project (or product), use this level. This is far more efficient and less error prone as to manually assign the same access rights for all repositories with the same characteristics.
  • Project Hierarchy level: If you grouped your projects / products into hierarchies, e.g. modelling your organizational structure, and you have access rights that apply to the assets of  an entire project tree, use this access level. Obviously you can mix access rights on this level with more specific access rights that only apply on the branch, repository or project level.
  • Server Level: If there are certain stakeholders that should get access to all repositories of an entire server (e.g. server admins and department leads), use this level.
  • Site Level: Use this level if certain access rights should spawn across multiple SCM servers. If you have a code search user or site admins that should have read access to all your repositories on all servers, this is the right place to configure. This is especially powerful if you have to deal with different version control systems as the level applies to all of them.
CollabNet TeamForge's supports all six levels in the asset dimension (what can be accessed) for Git, Subversion and CVS. Project hierarchy and site level permission support has been  recently introduced for Git. Have a look at this and this blog post for more details.

Now that we have investigated who can access what, the only dimension left is how, or in other words, which operations should be allowed for a certain stakeholder on a certain asset. Git servers like Gerrit support dozens of different operations, from fast forwarding branches and fetching commits to exotic operations like pushing signed tags, rewriting history (force push), deleting branches or rebasing a code review. In the picture above, an example of the fine grained Gerrit access rights are shown in the right column. For more details on Gerrit access rights, check out this link.

Fine grained access control operations are an advantage for enterprises. Imagine you only have a generic write operation and cannot differentiate between pushing commits to a branch and deleting that branch. If you grant write, you always allow both, although you do not like your developers to delete branches (they should just be able to update them). A fine grained model will have different operations for that, so you can differentiate between those two operations and only assign what is needed, following the least privilege principle. The principle of least privilege is the foundation for many standards around source code security and enterprise compliance, including PCI-DSSSSAE16 and DISA’s ASD STIG.

On the other hand, having 28 different operations at hand is really complicated. It requires lots of time to understand the specifics and master proper access right assignments. For that reason, CollabNet found some middle ground.We defined four easy to understand TeamForge SCM permissions displayed in the left column: View, Commit, Delete, Admin.

Furthermore, we introduced a bunch of so called repository policies. The picture above shows the policies provided out of the box in the middle column: Default, Optional Review, Mandatory Review and Custom.

These policies map the simple four TeamForge SCM permissions to the more complicated 28 Gerrit access rights. Depending on the policy, this mapping will differ: If you select a policy involving code review, the mapping will contain code review related operations as opposed to the default policy where code review is not in the picture. The following animated picture shows how depending on the selected repository policy, different Gerrit operations result out of the same TeamForge SCM permission:

Enterprises can modify the policies, TeamForge delivers out of the box. Furthermore, it is possible to define company specific policies – Eryk’s blog post shows how to define a repository policy for the Git-Flow model. Repository policy definition can be done remotely without the need to restart the server.

Last but not least, if you already mastered the 28 different Gerrit operation levels, there is also a custom policy that will switch off the TeamForge auto pilot and lets you define everything in Gerrit. Even in this case, the stakeholder dimension (who can access) and the asset dimension (what should be protected) are still controlled by TeamForge. A training video on our web site provides more details.

What to do with your visualization framework?

Now that you know about the three different dimensions of source code access control mechanisms, you can investigate whether your solution provides what you need. You will be able to shed some light on generic statements like “bulletproof” or “military grade” security and check whether the fine print really satisfies the security requirements of your enterprise.

If you are already using CollabNet TeamForge to manage your Git, Subversion and CVS repositories, you might have not been aware of all the different access levels within the three dimensions. Hopefully, you have a better picture now which knobs exists. If there are any questions how to find and use those knobs, just drop a comment to this blog post and my team will happily answer your questions.

Johannes Nicolai

Johannes Nicolai is CollabNet’s Development Manager leading all Git and Gerrit related development efforts. Furthermore, he is responsible for CollabNet Connect /synch, CollabNet’s platform to integrate TeamForge with third party ALM platforms. Johannes holds a Master of Science in IT Systems Engineering from Hasso Plattner Institut Potsdam and is a Certified Scrum Master. Before joining CollabNet five years ago, he was doing consulting on user centric design, developing cryptographic software and architecting SAP integrations. He is an Open Source enthusiast and contributes to many projects (check out https://www.ohloh.net/accounts/10619 for details).

Tagged with: , , , , , , ,
Posted in Enterprise Git, Git, Subversion, TeamForge
2 comments on “Bulletproof, Military Grade Security – Visualizing the Access Control Mechanisms of Your SCM Solution
  1. Germain says:

    Hi Johannes,

    Basically it means that when using “your policy” repository policy you can define only 4 local project roles to be map respectively on one of the 4 SCM permission. Do you plan in a near future to extend this number ?
    BR
    Olivier

    • Hi Olivier,

      if all your project roles should have different Gerrit access rights and you have more than 4 different roles, you cannot model the differences on SCM permission clusters (which are 4) alone. You either have to
      a) switch to the custom repo category
      b) figure out whether you can use Gerrit’s inheritance feature for your use case. For instance, many companies have a role for CI users. The number of CI user accounts per company is typically limited, so you can put them into one TeamForge user group and then assign the Gerrit access rights needed to the corresponding Gerrit group in Gerrit’s hierarchy above individual repositories so that it just inherits down. You could do similar things for all repositories of a TF project based on the project admin group as well (so you only have to setup per TF project once).
      c) completely script access right assignments based on your custom logic and push it to refs/meta/config
      d) a combination of a, b, c

      We plan to extend repository mappings to treat protected branches differently as part of our upcoming pull request feature, but that would probably not help you for the use case you have in mind. I take from your comment that you are interested in having an ability to decide upon the project admin flag what permissions to give in Gerrit. We may look into the feasibility of such a request but encourage you to experiment with solution b and tell us how far you got with that one.

      Best, Johannes

Leave a Reply to Johannes Nicolai Cancel reply

Your email address will not be published. Required fields are marked *

*