You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Phase 1: SVN 1.4 upgrade

This phase will focus on ironing out the details of the IPS-to-OIS rollout process.  The test server map-dev-svn1 will be set up to duplicate the features and user management of the existing svn.mit.edu service, with an upgrade to SVN 1.4.x being the only new user-visible feature.  The new service will be rolled out to OIS and existing repositories migrated.  svn.mit.edu will become separate from cvs.mit.edu at this time.

Phase 2: DAV, ra_svn, MAP passwords, possibly SVN 1.5

An IPS standard Apache HTTPD 2.x installation will be added to map-dev-svn1. The SVN server will be rebuilt with support for DAV (http(smile) and ra_svn (svn: without the SSH tunneling).  DAV access will support authentication with Kerberos, MIT certificates, and passwords over SSL.  ra_svn access will support authentication with passwords and possibly Kerberos.  Both access methods will also support anonymous read-only access if repositories are appropriately configured.

If Subversion 1.5 has been released by the time this phase gets underway, it will be used for this phase.  Subversion 1.5 is a requirement for Kerberos ra_svn authentication.

A new administrative web application, itself a MAP project running under Tomcat (probably without SASHServer), will be developed for this phase.  Initially the only feature of this application will be the provisioning of MAP passwords.  Users will authenticate to the application with certificates (or Touchstone if that's an option at this point in time) and will have the option to create, destroy, display, or change their MAP passwords.  Users do not get to choose MAP passwords; they are randomly assigned.  MAP passwords are only recommended when stronger authentication is not an option.  The web application will store a master list of MAP passwords, and a script will propagate the passwords to the /etc/shadow file (for SSH authentication) and to the svnserve and HTTPD password files.  MAP passwords eventually be reused when appropriate for other pieces of MAP infrastructure running on src.mit.edu and build.mit.edu, such as Bamboo.

Phase 3: Expanded administrative features

The administrative application will be extended to support new features, which can be rolled out one at a time.  Likely features include:

  • 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 group, to faciliate one project per repository.

In parallel with the above, the following new user management features will be implemented:

  • Support for users without Kerberos principals.  Touchstone and CAMS are prerequisites for this.
  • -svnadmin groups; these are subsets of -committers groups and control who has access to manage a repository through the web application. If a -svnadmin 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, or as the snap account.
  3. Accept a weak security model where users can gain access to other user's repositories with enough effort.

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.

  • No labels