3190 StarTeam Security Explained! Ron Sauers Principal Architect Borland Software Corporation

StarTeam Security? Help prevent unauthorized access to a StarTeam server by requiring strong passwords. Use an encrypted connection to secure data as it moves across the network. Grant or deny access to the assets stored in the repository.

StarTeam Security Security Model Access Test Algorithm Myths A New Model StarTeam SDK 2005 Best Practices

StarTeam Security Model

StarTeam Security Model Access Rights Access Control List Access Control Entry Privileges Ownership

Access Rights Permissions that may be granted or denied to a specific user or group. Some are generic, and apply to any type of object (e.g., “See an object and its properties”). Others apply only to objects of a specific type (e.g., “Check in file”).

Access Rights Permission. GENERIC_SEE_OBJECT FILE_CHECKIN . . .

Access Control List Describes how access rights are granted and denied to users and groups. An Access Control List (ACL) is a list of Access Control Entries (ACEs). The order of the ACEs in an ACL is significant.

Access Control List Java: ACE: class AclEntry ACL: AclEntry[] .NET: ACE: class ACE ACL: class ACL

Access Control Entry

ACEs in the SDK // true for a "Grant" ACE; false for a "Deny" ACE.  public boolean isGranted();    // The User or Group for which rights are granted or denied.  public int getID();    //true if the ID is a Group ID; false if the ID is a User ID.  public boolean isGroupID();    // The access rights that are granted or denied to this user  // or group, as a bit mask.  public int getPermissionFlags();

ACLs and ACEs

Types of ACLs Object-Level ACL Container-Level ACL Component-Level ACL

Object-Level ACL An ACL that is explicitly assigned to a given object. You can assign one to the object underlying any Item (File, ChangeRequest, etc.), or to any Project, View, Folder, PromotionState, Filter or Query. Access rights assigned to an object apply to that object only.

Object-Level ACL

Object-Level ACL

Object-Level ACLs in the SDK // Returns the object-level ACL assigned to this object,  // or null if this object does not have an object-level ACL.  AclEntry[] getACL();    // Sets the object-level ACL for this object.  public void setACL(AclEntry[] acl);

Container-Level ACL An ACL that applies to objects of a given Type (e.g., File or ChangeRequest) within a given container (e.g., Folder, View or Project). ACLs may be assigned at any level of the StarTeam containment hierarchy. The ACL found closest to a given object in the containment hierarchy is the one that applies to that object.

Container-Level ACL

Object-Level Folder ACL

Container-Level Folder ACL

Container-Level ACLs in the SDK // Returns the container-level ACL for objects // of the given type, or null if there is no such // container-level ACL. AclEntry[] getContainerLevelACL(String typeName);   // Sets the container-level ACL for objects // of the given type. public void setContainerLevelACL( AclEntry[] acl, String typeName);

Component-Level ACL An ACL that applies to a StarTeam component (e.g., to the Files component or the Change Request component). Currently supports access rights on Filters and Queries.

Component-Level ACL

Component-Level ACL

Component-Level ACLs in the SDK // Returns the component-level ACL for this type, // or null if this type has no component-level ACL. AclEntry[] getComponentLevelACL();   // Sets the component-level ACL for this type. public void setComponentLevelACL(AclEntry[] acl);

Group Privileges Global access rights that are always granted to members of a specific group. Override other access rights specified for individual objects or containers. StarTeam Administrators are typically granted special privileges.

Group Privileges

Group Properties Dialog

System Policy Dialog

Group Privileges in the SDK // Gets privileges granted to members of this group. public int getPermissionsFlags();   // Returns true if members of this group // are granted the given privilege.  public boolean hasPermission(int permission);   // Grants the given privilege to members of this group. public void addPermission(int permission);   // Revokes the given privilege. public void removePermission(int permission);

Ownership Most StarTeam objects have an owner. The owner is automatically granted full access rights. The actual owner of an object is not displayed anywhere in the StarTeam user interface!

System Policy

Security Model

StarTeam Access Test Algorithm

The StarTeam Access Test Algorithm To determine whether or not user U has access right R for a particular item I of type T … Test Privileges Test Ownership Find the Relevant ACL Test the ACEs in the ACL

Step A: Test Privileges 1. Check the value of the “Ignore group privileges” System Policy option. If this option is set, then skip the group privilege tests.   2. For each group G of which the user U is a member, check to see if G has been assigned the privilege R. If so, then the access test succeeds, and U is granted access.   3. Otherwise, group privileges do not apply. Continue.

Step B: Test Ownership 1. Check the value of the “Ignore object ownership” System Policy option. If this option is set, then skip the ownership tests.   2. If U is the owner of the object referenced by I, then the access test succeeds, and U is granted access.   3. Otherwise, object ownership does not apply. Continue.

Step C: Find the Relevant ACL Check for an object-level ACL associated with the ObjectID of I. If found, then it is the relevant ACL.   Otherwise, check F, the parent folder of I, for a container-level ACL for objects of type T. If there is one, then it is the relevant ACL.   Otherwise, search up the folder hierarchy. If F has a parent folder, then repeat step 2 with F = F’, the parent folder of F.  

Find the Relevant ACL … Otherwise, check the View for a container ACL for objects of type T. If there is one, then it is the relevant ACL.   Otherwise, check the Project for a container ACL for objects of type T. If there is one, then it is the relevant ACL.   Otherwise, then there is no relevant ACL. The access test succeeds, and U is granted access.

Step D: Test the ACEs in the ACL For each ACE in the relevant ACL … If the ACE does not apply to U, then skip this ACE. If the ACE does not specify access right R, then skip this ACE. If the ACE is a “Grant” ACE, then the access test succeeds, and U is granted access. If the ACE is a “Deny” ACE, then the access test fails, and U is denied access.

Test the ACEs in the ACL … If no ACE in the ACL applies to both U and R, then the access test fails, and U is denied access.

StarTeam Security Myths Common misconceptions regarding the StarTeam Security Model.

Myth: Access rights can be assigned to an item. You are actually assigning access rights to the underlying object that is referenced by the item. Access rights affect not only the selected item, but also any other items in its share tree that have the same ObjectID. When an item branches, the ObjectID changes!

Myth: If you don't explicitly specify an access right, it is granted by default. This is true only in the rare case when there is no relevant ACL. Be particularly careful when setting access rights via the StarTeam SDK. An empty array and a null ACL are very different.

Myth: If you don't explicitly specify an access right, that access right is inherited from the parent container. There is at most one ACL that is relevant in any given context. There is never any attempt to somehow combine two ACLs when performing an access test.

Myth: You can determine whether a given access right is granted or denied by looking at the Access Rights dialog. The Access Rights dialog shows only those access rights that are explicitly specified on the selected object.

A New Look at Access Rights Is there an alternate model we might use to help better understand access rights?

The Effective ACL Gather all of the information that is relevant to determining the access rights for a given item. Represent it in a single, self-contained Effective ACL. Testing the ACEs in the Effective ACL gives the same results as the full access test algorithm.

Explicit and Implied ACEs Explicit ACE - explicitly stored in an ACL somewhere in the StarTeam repository (from an object-level ACL or container-level ACL). Implied ACE - represents security-related information that comes from somewhere outside the relevant ACL.

Implied Privilege ACEs Test Group Privileges: For each group G of which the user U is a member, check to see if G has been assigned the privilege R. If so, then the access test succeeds, and U is granted access. Group privileges are represented in an effective ACL by including an implied ACE for each group that has been granted privileges.

Implied Ownership ACEs Test object ownership: If U is the owner of the object referenced by I, then the access test succeeds, and U is granted access. Object ownership is represented in an effective ACL by including an implied ACE that grants full access rights to the user who is the owner of the object.

Implied Deny ACEs When there is a missing ACE in the ACL: If no ACE in the ACL applies to both U and R, then the access test fails, and U is denied access. Access rights are completely specified if there is some explicit ACE in the ACL that either grants or denies every access right to the All Users group. Add a single implied ACE to the end of the effective ACL that denies the unspecified rights to the All Users group.

Implied Grant ACEs When there is no relevant ACL: If no relevant ACL was not found, then the access test succeeds, and U is granted access. Add a single implied ACE to the end of the effective ACL that grants all access rights to the All Users group.

An Example

Benefits of Effective ACL Model All security-related information that is relevant in a given context is collected and summarized. Rules that are implied by the access test algorithm are made explicit. It is always possible to explain the results of any access test in terms of the effective ACEs that were determinative.

Benefits of Effective ACL Model

New Features in StarTeam SDK 2005

New in StarTeam SDK 2005 ISecurableObject ISecurableContainer AccessRightsManager EffectiveACE AccessTestResults

ISecurable interface ISecurable { // Get/set the object-level ACL.     AclEntry[] getACL();     void setACL(AclEntry[] acl);       // Performs an access test against this object.     boolean hasPermission(int permissions);       // Returns this object's parent container.     ISecurableContainer getParentContainer();       // Returns the type of this securable object.     Type getType(); }

ISecurableObject // A securable object that has an owner. interface ISecurableObject extends ISecurable {       // Returns the userID of the user     // who currently owns this object.     int getOwner();       // Changes the owner of this object     // to the currently logged-on user.     void acquireOwnership(); }

ISecurableContainer // An object that can have container-level access rights. public interface ISecurableContainer {       // Get/set the container-level ACL. AclEntry[] getContainerLevelACL(String typeName);     void setContainerLevelACL(AclEntry[] acl, String typeName);       // Performs a container-level access test.     boolean hasPermission(int permissions, String typeName);     // Returns this object's parent container.     ISecurableContainer getParentContainer(); }

AccessRightsManager Provides the following new features: Determine the effective access rights in a given context . Perform access tests against the effective access rights.

AccessRightsManager // Determines the effective access rights // for the given securable object. EffectiveACE[] getEffectiveACL(ISecurable obj); // Performs an access test against // the given effective access rights. public AccessTestResults accessTest(int userID,                                      int permissions,                                      ISecurable obj);

EffectiveACE // Describes the source of this effective ACE public boolean isFromGroupPrivileges(); public boolean isFromObjectOwnership(); public boolean isFromObjectACL(); public boolean isFromContainerACL(); public boolean isFromMissingACE(); public boolean isFromMissingACL(); . . .

EffectiveACE Provides a human-readable description: These access rights are explicitly granted to members of the "All Users" group in the container-level Access Control List (ACL) for objects of type Change Request defined for Project “StarDraw”.

AccessTestResults Describes the results of an access test. Indicates whether the requested access rights were granted or denied. Also provides an explanation for the decision, expressed relative to the EffectiveACEs.

AccessTestResults

Access Testing in the SDK

Simplify implementation and maintenance of access rights. Best Practices Simplify implementation and maintenance of access rights.

Design with security in mind. Security requirements are often overlooked when designing the structure of a StarTeam project. Are there some files that will have different access rights than others? Are there different groups within the organization that will require access to different subsets of the files? Changes made early are typically easier to make than changes made to a mature project.

Minimize the number of security control points. Create as few ACLs as possible. Every ACL is critical project data that must be maintained over time. A project that has one container-level ACL for objects of type File is much easier to manage than a project that has a separate object-level ACL for every file.

Secure at the container level. Set access rights at the container level whenever possible. This is especially true for items within a Folder. It is better to have a container-level ACL on a parent folder than it is to have separate object-level ACLs on each item in the folder. Container-level access rights should be set as high in the containment hierarchy as possible.

Minimize the number of users who can change access rights. Not all users understand the security model. Getting it wrong can have serious consequences. Limit the number of users who have the right to change access rights. Grant the "Change object access rights" privilege to a single "StarTeam Security Administrators" group. Never explicitly granted this right in any ACL.

Avoid user-specific ACEs. A user is granted access rights based on his or her role in the project. It is better to create a Group whose name reflects the role, and assign access rights to that group Access rights can be updated by changing group membership, rather than by reviewing and updating ACLs. Handles a growing team, with multiple users filling the same role.

Avoid ACLs on items that branch. Access rights are assigned to the underlying object that is referenced by the item. Two items with the same ObjectID necessarily have the same object-level ACL Two items with different ObjectIDs have independent ACLs. When an item branches, it gets a different ObjectID. Avoid ACLs on Folders that might branch.

A Problem Scenario Create FolderA. Assign a container-level ACL with the required access rights. Create a branched view for a parallel development stream. The branched view also has a reference to FolderA, with the same objectID and ACLs.   In the parallel development stream, rename FolderA to FolderB. FolderB has a new objectID, and no longer shares ACLs with the main view.

A Problem Scenario Anyone changing the properties of a Folder that has assigned ACLs must be aware of the implications with respect to security. Whenever assigning object-level or container-level access rights to a Folder, ensure that only security administrators are granted the "Modify properties" access right.

Use sharing when it simplifies the implementation. Conflicting requirements can complicate the access rights implementation. Assign a container-level ACL to the folder, and override with object-level ACLs on selected files? Avoid object-level ACLs on individual files. Create a separate folder with alternate ACL. Share items between folders. Do not branch on change!

Consider disabling the object ownership feature. Owner of an object is automatically granted full access rights. Owner of an object is not displayed anywhere. Consider disabling the object ownership test in the System Policy dialog. Is there a user who should be granted full access rights? Design that into the project.  

Questions?

Thank You Please fill out the speaker evaluation 3190 StarTeam Security Explained! Please fill out the speaker evaluation You can contact me further at … Ron.Sauers@borland.com