...

• Manage the authorized_keys file of a user account, and allow public key authentication for SSH.
• Configure commit emails for a repository.
• Manage access control for a repository.
• Manage integration of a repository with other MAP infrastructure such as Bamboo.
• Receive a partial or complete dump file of a repository.
• Post a dump file to be loaded into a repository.
• Automatically provision a new repository for an existing -users and -admin ownership group, to faciliate one project per repository.

...

• Support for users without Kerberos principals.  Touchstone and CAMS are prerequisites for this.
• -admin groupsAdmin lists; these are subsets of - committers groups and control who has access to manage a repository through the web application. If an -admin groups does not exist, all members of the -committers group will have access.

Issue: Security architecture and hook scripts

The current svn.mit.edu service uses ssh tunneling to run svnserve as a different uid for each svn user.  Group ownership is used to restrict read and write access by these svnserve processes.  Several projects have corresponding "snap" accounts which are allowed to create arbitrary hook scripts for a repository.  Hook scripts are executed as the committing user, so a hook script created by one user cannot gain access to a second user's repository.

As we add DAV and ra_svn access, we will not be able to trivially preserve this security model.  With DAV access, repository manipulations are done with the uid and gid of the web server process; with ra_svn access, with the uid and gid of the svnserve network daemon.  Hook scripts are also run with these identities.

To make commits work via these daemons, the web server or svnserve uid will need to be added to the repository's -committers group.  (Thus, commit access via daemons can be disabled by omitting the relevant uid from the -commiters group.)  For read-only access via daemons, either the relevant uid needs to be in the repository's -commiters group or the repository needs to be world-readable on the server.

Since all hook scripts will be run with a single UID and that UID will have write access to many repositories, we are limited to several options for the hook script security model:

1. Do not allow custom hook scripts for repositories accessible by the daemons--no "snap" accounts with write access to the hooks directories of such repositories.
2. Develop machinery to make custom hook scripts execute as the committing user.
3. Accept a weak security model where users can gain access to other user's repositories with enough effort.

...

• By default, the admin list is the commiters group itself.

Security Model

Here is the security model to be used when phase 2 is complete:

• Each repository has an associated owner group containing the users allowed to commit to the repository.
• User shells are set to exec-svnserve, so they do not have unrestricted shell access.  (This is not a strong guarantee; they will be able to run arbitrary commands on the server as themselves via hook scripts if they have control of an appropriate local shell account.)
• User homedirs are set to /var/user/USERNAME.  Generally these directories will only contain SSH authorized_keys files.
• Some owner groups will contain local shell accounts which have regular shells.  Shell account homedirs are set to /var/shellacct/USERNAME.
• Owner groups will contain the svnserve and/or www users if they allow commits via svn:// or http://.
• Repositories will be owned by root and group-owned by the repository's owner group.
• Most of the directories and files in a repository will be owner-writable and group-readable.  The db and userhooks directories will be group-writable.
• The directories and files in a repository may be world-readable depending on user preference.  World readability will be required to allow anonymous read-only browsing if the group does not allow commits via svn:// or http://.
• Access via svn+ssh:// will be conducted by an svnserve process with the uid of the user.
• Access via svn:// will be conducted by an svnserve process with the uid of svnserve.
• Access via http:// will be conducted by an httpd process with the uid of www.
• The hooks directory will be populated with standard scripts of our own devising, which will be executed as the uid specified above.  It is important that users not be allowed to determine what actions these hook scripts take or they would be able to gain control of the svnserve and www accounts and thus write access to other users' repositories.  The behavior of these standard hook scripts will be controlled by configuration files in the repositories which can be edited by the administrator or (in phase 3) via the admin app.
• As their first or last action (not yet determined), each hook scripts will execute a subsidiary script in userhooks via a setuid wrapper which changes uid to the committing user.  These scripts can be user-determined via the owner group's local shell account if the owner group has one.

Since phase 1 does not include access via svn:// or http:// it will use a more relaxed security model where repositories are writable by their owner groups and can determine their own hook scripts.  Some repositories may be grandfathered into phase 2 with this model, but only if their owner groups do not allow access via svn:// or http://.

Inventory of Configurable State

User configuration

• What public keys are allowed for SSH access
• Whether the MAP password exists and what it is

Group configuration

• Whether commit access through DAV is possible for repositories owned by this group
• Whether commit access through the svnserve daemon is possible for repositories owned by this group
• What this group's admin list is (not user-configurable)
• What this group's shell account is, if any (not user-configurable)
• The namespace prefix for automatic provisioning of repositories, if any (not user-configurable)

Repository configuration

Some of these can only apply to a repository using the standard hook scripts. 

• Whether the repository is world-readable on the server (allows read-only DAV/svnserve access if commits through DAV/svnserve are disabled)
• The access control file for the repository
• Where commit emails for the repository go, if anywhere