SLAC Root Access Request

If running taylor is not feasible (either because it does not support your platform or because you need greater autonomy to configure your system), then it is up to you, as the system administrator, to enforce the above four requirements. We rely on you to make a conscientious, good-faith effort to abide by the spirit of the above requirements as well as complying with the detailed, but inevitably incomplete, rules outlined below. If you fail to do so, we reserve the right to remove NFS access for your machine without notice (note that this will require that we reboot or shutdown your machine).

Guard the root Password

You must exercise reasonable caution with the root password, e.g., you must not choose a weak password nor give it to users who have not agreed to these requirements and you must change it at least every six months.

Coordinate Account Management

We strongly recommend that you run NIS and use our central passwd and group files to define all or most of the accounts needed on your machine. Note that it is possible to use only certain entries from the NIS passwd file and to override some, though not all, fields from the NIS entry for a particular account. However, if you do use our passwd file, you will need to ensure that your users can access either their central home directories, or local home directories using the path specified in that file. You may also need to install one of the popular alternative shells, such as tcsh or bash, that might be needed by some of your users.

If you need to create any local accounts or groups (other than the special root-scs account described in point 2., below) you must obtain agreement from all of those who will be acting as system administrators for the machine to all of the following requirements:

1. You must consult with SCS before changing any of the special-purpose low-numbered accounts or groups that are provided by the OS vendor.
2. There must be a SLAC contact (i.e., someone who has signed SLAC's "Computer Account Responsibilities" form and is in the SLAC personnel database) for every local account. If no one else can be identified, you, as the system administrator, will be that contact and might be held responsible for the actions of any non-SLAC user to whom you have given an account. (Thus, you may want to ask your users to obtain a central UNIX account, in which case there may be no need to create a local account for them.)
3. You must take care not to compromise the uid- and gid-based security of our NFS file servers. This means that each such account or group must either:
   1. be totally disjoint from any account or group that appears in our NIS passwd and group files, i.e., no duplication of username, uid, groupname or gid between the entry in your local passwd or group files and any accounts in our NIS databases (to insure that uids and gids will never conflict, you must use numbers from 20000 on); or,
   2. duplicate the username and uid, and specify compatible group information, for an entry in our NIS databases (provided, of course, that this account is created for the same person who owns the corresponding NIS account). "Compatible group information" means that the local account must not belong to any NIS groups that the NIS account does not belong to, and that the primary group for the local account must either be a local group or else the same as the primary group of the NIS account. You may also add memberships to additional local secondary groups.
4. You may install special-purpose user accounts or groups required by third-party software; however, you must exercise reasonable caution and good judgment to avoid compromising NFS security. If you have any doubts about a piece of software or its installation procedures, please contact SCS for advice.

Maintain Security

You must maintain the system with a reasonable degree of security, as determined by SCS. This requirement includes but is not limited to, such things as regularly installing security patches, removing or disabling local accounts when users leave SLAC, reporting suspicious activities to SCS, etc.

You must also contact the SLAC Security Officer (security@slac.stanford.edu) to arrange an initial scan before your system is granted NFS access. If your machine is capable of booting more than one operating system (e.g., both Linux and Windows NT), you must so inform the Security Officer, and arrange to have it scanned when running each such OS. Thereafter, the Security Officer may rescan your machine from time to time. If you are concerned that such scans might disrupt mission-critical functions, you may contact the Security Officer to arrange mutually agreeable times to carry them out.

Grant SCS Root Access

You must add a local account (or, possibly in the future, several local accounts) as described in the file,

  /afs/slac/service/admin/non-scs/passwd/passwd

This file will contain one or more standard passwd file entries including encrypted passwords. You must install them according to the normal procedures on your system (including whatever steps are necessary to move the passwords to a more secure "shadow" passwd file, if available). One of these accounts will be named "root-scs" and will have both uid and gid of zero, making it, for most purposes, equivalent to the real "root" account on your system.

You must also agree to update these accounts (e.g., with new encrypted passwords) when notified by SCS.