Jaa

Team Build: Securing your build type

  • Artikkeli

Information applies to Beta3 and beyond releases and subject to change

Creation of build type is a two step process in which some files are generated and then checked-in to the source control. For a Build Type named MyBuildType for the Team Project MyTeamProject these files are checked-in at the server location $/MyTeamProject/TeamBuildTypes/MyBuildType.

The user interface and all the TeamBuild web methods provide policy validation to ensure that the Build Types remain secure. For example if you do not have Administer Build privilege then you will not be able to launch the Build Type Creation Wizard. Similarly to start a build through the Build form, command line or directly using the web method, security validations are made.

However, build types remain checked into source control at the location mentioned above. So an user can directly go to source control and modify them. Let's take a scenario. The system administrator who has all the required privileges creates a Build Type named Nightly and then schedules build so that automatically builds are fired daily at 8:00 p.m. An user ArthurDent who is not an admin but belongs to some group which has source control checkin permission checks out the file $/MyTeamProject/TeamBuildTypes/Nightly/TfsBuild.proj
and changes the drop location so that instead of the built bits getting dropped (copied) to the official location, gets copied to the users hard disk which he shared out as \\ArthurMachine\myshare.

Since all groups having checkin permissions will not essentially have Administer build, Start a build permissions. This can be considered as a privilege elevation risk.

The obvious question that comes to our mind is, does TeamBuild try to do something to put a check on these risks? The answer is yes. But a part of the responsibility does reside on the system administrator. Let's first see what TeamBuild does and then we can go into what the administrator can do to maintain security.

When a Build Type is created for the first time, TeamBuild creates the folder $/MyTeamProject/TeamBuildTypes. After creating this folder it applies some source control Access Control Locks (ACLs) so that only a subset of the users can modify files in this folder. The following permission changes are made on it.

  1. All groups that have Administer build privileges are given checkout/checkin permissions.
  2. Checkout/checkin permissions are removed from groups that do not have Administer build privilege
  3. Any group that already had these permissions explicitly denied are not given permission even if they have Administer build privilege
  4. No changes are made to the permissions of admin accounts.
  5. All Build Types created and all files generated and checked in are made to inherit permissions from the TeamBuildTypes folder.

All of the above ensure that the ACLs are in line with the Build security policy. However, once a Build Type has been created, the permissions (ACLs) are not changed on the TeamBuildTypes for subsequent build types. This gives the administrator chance to override or customize the ACLs.

Interesting points to note

  1. ACLs are set only for when the first Build Type is created
  2. ACLs are set only on the TeamBuildTypes folder and all BuildTypes inherit their ACL from it

The TFS Administrator has  to ensure that once the Build Type is created the $/MyTeamProject/TeamBuildTypes is secure. He can try doing the following to plug any security hole

  1. Once a TeamProject has been created the admin should himself create a Build Type as soon as possible.
  2. Give administer build privilege only to people/groups who need it. Since this is required only to create/modify Build Types and not to start a build it should reside only with a small subset of people.
  3. After creation of the first Build Type go to the security tab of the TeamBuildTypes folders property page in source control to ensure that the ACLs are set correctly. If required, customize the ACLs.
  4. When Administer build permission is given/revoked to any group the checkin/checkout permissions on the TeamBuildTypes folder does not automatically change. The admin needs to keep both in sync. So if you give Administer build privilege say to the Contributors group then you need to give checkin/checkout permission to the same group for the $/MyTeamProject/TeamBuildTypes folder. In case you do not give the permission and the user tries to launch the Build Type creation wizard, he will get an error message indicating that. The potential risk is when you revoke the privilege. If admin forgets to remove the checkin/checkout permission then that user can go and directly checkin a BuildType.

As I have said at the beginning, this blog entry is on code which are in development and can change at any time. I will try to keep this post updated in case we make any changes to security handling....

Comments

  • Anonymous
    November 08, 2006
    Is it possible to set permissions on an individual build type?  For example, can you say that User1 has "Start_Build" permissions for "Build Type 1" but does not have "Start_Build" permissions for "Build Type 2"?Thanks,-Ben
  • Anonymous
    November 11, 2006
    There isn't per build type permission. However you can use the workaround of going to source control and removing read permission for the restricted Build Type'sTfsBuild.proj files.
  • Anonymous
    February 06, 2008
    That workaround doesn't seem to work - at least not in TFS2008.