Subsections

• 15.1 Privileges required for executing a CVS command
• 15.2 Access Control Rules Setup
• 15.3 ACL Enforcement
• 15.4 ACL Examples
  • 15.4.1 List Only Access
  • 15.4.2 Deny rule on a file
  • 15.4.3 Read Only Access
  • 15.4.4 Using Sub-Groups
  
  
• 15.5 Configuring Access Control Properties

---

15 ACL (Access Control List) Management

The Access Control or authorization mechanism in WANdisco Security Agent is based on the concept of a set of valid principals with adequate privileges to access a secured resource. By default ACLs are not visible, to enable go to System tab, select Show Role ACLs and click Save. The ACL management features allow an administrator to:

• Implement Role Based Access Control (RBAC)
• Use CVS client's IP address pattern to restrict access
• Specify any number of Allow or Deny Rules
• Create ACLs with regular expression patterns to describe user, groups, files/directories/modules and branches.
• Assign privileges like list, read write, admin to principals.
• Setup ACLs across multiple CVSROOTs and modules

Here are the definitions of the commonly used terms when describing the WANdisco Security Agent's ACL mechanism:

Login id

The actual CVS account name that can be successfully authenticated by CVS or SSH daemon (if using the ext SSH protocol). The CVS login id is also the primary key for a user in the WANdisco Security Agent's user database.

Principal

Principal can be any valid user or group. After authentication the WANdisco Security Agent maps a login id to a set of principals that include the actual user and all its associated groups and sub-groups.

Resource

Resource is a file, directory, module or the CVSROOT itself. Resource patterns can be specified as Perl-style regular expressions in the ACL. A resource needs to be a fully qualified (with respect to the CVSROOT) path to disambiguate same file/directory names across multiple modules or CVSROOTs. All directory paths, including a CVSROOT should be specified in the slash-terminated form. For example, specify /a/b/c/, not /a/b/c.

IP Mask

A Perl-style regular expression specifying the CVS client's IP address. It is used in the ACL to restrict access to a specific client network, subnet or a machine.

Privilege

Privileges are needed by a user to execute specific CVS commands. The WANdisco Security Agent supports four privileges:

List

Read

Write

Admin

The Admin privileges are granted by assigning a user into the special system group Admin. Explicit ACLs need not be set on the Admin group.

15.1 Privileges required for executing a CVS command

The privileges are ordered. In other words if a principal has Admin privilege, they also have the other three: List, Read, Write. If a principal has Write privilege, they do not get Admin privilege but have the other two: List, Read. If a principal has Read privilege, they do not get Admin and Write privileges but have the List privilege. If a principal has only List privilege, they do not get Admin, Write, Read privileges.

The following is the mapping of actual CVS commands to minimum privilege needed to execute them:

15.2 Access Control Rules Setup

The majority of access control needs can be addressed with Role and Group management but in the case that you need finer grained control you can also create individual ACLs to address your organizations needs. This view is disabled by default. To enable it go to the System tab, select System Config, .

The WANdisco Security Agent ships with no default rules. By default everyone is denied. This is essential for security - it closes the window of vulnerability that would have allowed everyone full access between the time the product is first installed and the admin creates access rules. In order to grant access, the administrator has to explicitly create allow rules.

Using the ACL editor from the web console, the admin can create allow or deny rules.

Perl style regular expressions can be used wherever patterns are allowed. Principal (user/group) or IP patterns for instance - engineering.* (note the dot) or 217.[0-9]+ are all valid patterns. By default the HEAD branch is specified but you can enter a regular expression just as well - release9.0_.* for instance. Note: With the Perl regular expression syntax, if you need to use the '.' (dot) character literally, you need to escape it with a backslash, otherwise '.' (dot) will match any character. To learn more about regular expressions look at a tutorial here.

Multiple rules can be edited atomically using the WANdisco Security Agent. When you submit changes to ACLs, the WANdisco Security Agent guarantees either all the rules are updated or none at all. This ensures consistent rules database across multiple sites, with any pattern of failures.

15.3 ACL Enforcement

The following steps are followed by the WANdisco Security Agent's ACL engine when making an allow or deny decision on a CVS command the user is trying to execute:

1. Check if a user is registered/licensed in the WANdisco Security Agent's user database. If not access is denied.
2. Obtain the list of groups a user belongs to as part of their principal set.
3. Check if anyone of the principal is allowed access based on several parameters:
   • Map principal to privileges they have been granted
   • For each resource and branch, the principal is trying to access check if there is a matching rule
   • A rule is matched if the principal's name, IP address, branch and file/directory matches with the patterns specified in the ACL.
   • If matching ACL rule is found, see if it denies access. If a matching deny rule applies then the principal is denied access to that resource.
   • If no matching rules are found, the principal is denied
   • If no deny rules match and there exists at least one allow rule, the principal is allowed access to that resource.
4. If the user is allowed access to ALL of the resources via at least one principal per resource, then user is allowed to execute the CVS command else the command is denied.

15.4 ACL Examples

To illustrate how the ACL enforcement works, lets walk through several examples below:

15.4.1 List Only Access

User doe belongs to group engr. The administrator has setup the following rules:

The user is allowed to execute the following commands that require only list privilege:

$ echo $CVSROOT
:pserver:doe@mypc:/data/cvsroot
$ cd /home/ecommerce/
$ cvs status
$ cvs ls

The user is denied access when executing the following commands that require read or write privilege:

$ cvs update foo
cvs acl: Access Denied: The CVS administrator has not granted
cvs acl: you sufficient permissions to execute this command.
cvs acl: Please contact your local CVS administrator for help.
cvs acl: Aborting the cvs operation.

$ cvs commit -m "my changes" 
cvs acl: Access Denied: The CVS administrator has not granted
cvs acl: you sufficient permissions to execute this command.
cvs acl: Please contact your local CVS administrator for help.
cvs acl: Aborting the cvs operation.

The user is denied access when executing the following list commands from subnet 10.23.1:

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:09:5B:19:3E:F8
          inet addr:10.23.1.7  Bcast:10.23.1.255  Mask:255.255.255.0
...
$ cvs status
cvs acl: Access Denied: The CVS administrator has not granted
...

15.4.2 Deny rule on a file

User jane belongs to group build-engr. The administrator has setup the following rules:

The user is allowed to execute the following command:

$ echo $CVSROOT
:ext:jane@mypc:/data/cvsroot
$ cd /home/build
$ ls
foo.c bar.v secret.make
$ cvs update secret.make
$ cvs ci -m "new" foo.c bar.v

The deny rule above doesn't restrict read access to secret.make, only write access is limited.

The user is denied access when executing the following command:

$ cvs ci -m "new changes"  secret.make
cvs acl: Access Denied: The CVS administrator has not granted
...

In this example, the deny rule is used to restrict access to the file secret.make. Deny rules can be applied to a file or directory pattern as well.

15.4.3 Read Only Access

User jane belongs to group qa. The administrator has setup the following rules:

The user is allowed to execute the following commands that require only list privilege:

$ echo $CVSROOT
:ext:jane@mypc:/data/cvsroot
$ cd /home/ecommerce/
$ ls
foo.c bar.v
$ cvs status foo.c
$ cvs ls
$ cvs up -r rel_1_0 bar.v
$ cvs diff -r rel_1_0 foo.c

The user is denied access when executing the following commands:

$ cvs ci -m "new changes"  
cvs acl: Access Denied: The CVS administrator has not granted
...
$ cvs up -j rel_2_0
cvs acl: Access Denied: The CVS administrator has not granted
...
$ cd /home
$ cvs co ecommerce
cvs acl: Access Denied: The CVS administrator has not granted
...

The last checkout command is denied because to checkout from the CVSROOT requires read privilege not only on the module ecommerce but also the top level cvsroot /data/cvsroot.

To checkout the module the administrator would setup access rules as:

15.4.4 Using Sub-Groups

User bigoram belongs to parent group div-engr, while user smalloram belongs to sub-group nyc-engr of div-engr.

The administrator has setup the following rules:

The user bigoram belongs to both the groups (div-engr, nyc-engr), therefore is allowed to execute the following commands:

$ echo $CVSROOT
:pserver:bigoram@mypc:/data/cvsroot
$ cd /home/dvd
$ cvs update -P -d sfo
$ cvs update -P -d nyc

The user smalloram is belongs to only the group (nyc-engr), therefore is allowed to execute the command:

$ echo $CVSROOT
:pserver:smalloram@mypc:/data/cvsroot
$ cd /home/dvd
$ cvs update -P -d nyc

The user smalloram is denied access when executing the following command:

$ cvs -z6 update -P -d sfo
cvs acl: Access Denied: The CVS administrator has not granted
...

15.5 Configuring Access Control Properties

The following properties in the prefs.xml file can be used to control the ACL engine:

<Security>
 <AccessControl>
  <Enable>true</Enable>
 </AccessControl>
</Security>

By default, the WANdisco Security Agent has access control enabled. To turn it off set /Security/AccessControl/Enable to false.