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.projand 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.
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
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
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....