...

• Support for users without Kerberos principals.  Touchstone and CAMS are prerequisites for this.
• Admin lists; these are subsets of committers groups and control who has access to manage a repository through the web application. By default, the admin list is the commiters group itself.

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, or as the snap account.
3. Accept a weak security model where users can gain access to other user's repositories with enough effort.

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://The third option is probably not acceptable to us, particularly after we add support for non-Kerberos users, but it's worth noting that web hosting has a similar security issue and most web hosting providers have taken the third approach.

Inventory of Configurable State

...