Superuser/NFS Privileges Form

		Superuser/NFS Privileges	UNIX at SLAC Security at SLAC
		Updated: 6 Oct 2006

Certain privileges associated with the superuser or root account are needed to administer and maintain a UNIX system. This form constitutes an agreement between the submitter and SCS to share the privileges on, and thus the responsibility for, such a system. There are two primary reasons why you might want to request such shared responsibility:

to delegate most of the routine system administration to SCS while retaining the ability to resolve problems or change the machine's configuration when necessary; or,
to comply with SCS requirements in order to obtain access to SLAC's central NFS fileservers on a system you otherwise plan to administer by yourself.

In either case, you will need to install and run a program called Taylor. Taylor normally runs once a day (though other schedules are possible) and is the primary tool used by SCS to do all UNIX (and Linux) system administration.

If you do not want assistance from SCS in maintaining your UNIX system and do not require access to NFS, you need not submit this form. Nevertheless, you are responsible for maintaining the security of any UNIX workstation which you attach to the SLAC network, since any break-in on your machine threatens every machine at SLAC. We recommend, therefore, that anyone with superuser privileges on a SLAC machine read and comply with the security requirements discussed below.

Overview of Superuser Privileges

Every UNIX system has a superuser account with a UID of zero and a username of root. This account is considered to be trusted and is therefore allowed to bypass the usual security features of the operating system in order to perform administrative and maintenance operations. There may be additional accounts with UID 0 which have, for most purposes, the same privileges as root.

One can invoke superuser privileges by logging in as root or by using the su command to become root temporarily. However, both of these methods require that you know the root password, which has several drawbacks:

You need to remember, and regularly update, an extra password.
If several people need to share responsibility for administering a system, they need to share the password. This presents security and manageability concerns:
- Accountability: there is no record of who has done what.
- You need to coordinate password changes with several people.
- You need a secure way to distribute new passwords from time to time.
Privileges cannot be conferred selectively: once you know the root password you have all superuser privileges.

The sudo command provides a useful alternative:

It permits selected users to run commands either as root or as some other user without dealing with any additional passwords.
Users known to sudo may be authorized to run either a subset of commands or all commands as the target user.
Although users must authenticate themselves by typing their personal passwords, a given authentication is "remembered" for a short time so that immediately following sudo commands do not require retyping the password.
All commands are logged, providing accountability and recoverability.
There is very little need to run a root shell and thus much less likelihood of making a catastrophic mistake: you simply prefix commands that require superuser privileges with "sudo" while running in your normal shell.
If necessary (and authorized), a root shell can still be obtained via the command, "sudo -s" (though for the reasons listed above you should avoid doing this as much as possible).

Overview of NFS Security

When files are shared via NFS, the various systems involved must be administered in a coordinated fashion to preserve the integrity of the files and the security of the hosts. To ensure such coordination, we restrict access to SLAC's central file servers to hosts meeting certain requirements.

In order to enforce the normal UNIX user- and group-based access rights to files, it is essential that an NFS server and all its clients share consistent user and group databases. Most systems at SLAC use our centrally-maintained NIS user and group files, with AFS authentication, for this purpose. However everyone with superuser privileges on an NFS client machine can, potentially, add or override user accounts on that machine; they can also compromise the security of that machine, permitting a malicious intruder to attack files on the NFS server as well as on the compromised client. For these reasons, we require that everyone with such privileges on an NFS client system must submit this form to acknowledge that they have read and understood these conditions and agree to abide by them.

Strictly speaking, ensuring consistent user and group databases is only necessary on NFS client machines. However, it's a good idea on all SLAC machines and is not particularly difficult to implement if everyone follows the local account rules below. We therefore require it on all machines running Taylor, even if they do not happen to be NFS clients.

Guidelines for Requesting Superuser Privileges

Before requesting superuser privileges we suggest you think a bit about whether you really need them. If UNIX system administration is not an important part of your job description, and if you have no special requirements that are likely to require such privileges, we recommend that you let us manage your Linux workstation for you. Learning about system administration in UNIX, tweaking the operating system in various ways, and taking care of routine maintenance tasks such as installing security patches can take a lot of time. Moreover, to the extent that you customize your system, you make it more difficult for us to monitor SLAC systems for security, reliability and performance or to assist you when you run into trouble. If you decide you don't really need superuser privileges but do need NFS access, you can use the simpler Non Superuser/NFS Access Request form instead of this one.

If you nevertheless feel that you need superuser privileges in order to get your work done, the next question is whether you need to know the password for the root account or only need certain sudo privileges. SCS strongly recommends that you only request sudo privileges. As long as AFS authentication is working, a user with sudo ALL should be able to do anything root can do except attempt to recover from a corrupted system disk; and since the introduction of journaling filesystems, such problems are extremely rare. Even if you really do need root, you should consider requesting sudo as well and using it instead of the root password whenever possible.

If you only need the ability to run a few privileged commands, e.g., mount and umount, please consider requesting sudo for a subset of commands instead of sudo ALL.

As a general rule, SCS grants superuser privileges to the primary user and/or the system administrator of a system (or a small number of their designees), as listed in our CANDO database. You can find out who is currently listed in these roles for your system by issuing the command,

node -long host-name

If this information is not correct, please submit a CANDO update request before submitting this form.

SCS also requires that the password for any account with special privileges must be changed at least every 6 months. If you are requesting sudo privileges and have not recently changed your password, please change it via the password command before submitting this form.

To request superuser privileges on a UNIX system (or a group of systems), or to notify us that you already have such privileges, please fill out and submit the following form. The form should be filled out by each person who has or is to receive the privileges since it constitutes an agreement to abide by the conditions outlined on this page. If the system has, or is to receive, a private root password, each person who knows the password should fill out the form. If you are not the primary user or system administrator for the system(s), you should ask one of those individuals (or the group czar) to send mail to unix-admin to approve the request. Please ask them to include an explanation of why you need the requested privilege and what your role is with respect to the system.

To avoid delays in processing the form, please be sure to complete each non-optional field and answer every question.

Note: If the system has previously qualified for, and received, NFS access and has just been re-installed and re-taylored, with no other changes to it's configuration or to its set of users with superuser privileges, it is not necessary to re-submit this form.

Your full name:
Your phone extension:
Your email address:
Your UNIX username:
Host(s):	(You may specify a list of hosts or "workgroup=work-group-name for a Taylor workgroup.)
Person to contact for approval (optional):

Privileges Requested

sudo privileges on this host or group of hosts:

	I need `sudo ALL`.
	I need other (i.e., more limited) `sudo` privileges. (Please specify what commands are needed in the Additional Information field.)
	I already have `sudo` privileges.
	I do not need `sudo` privileges.

Access to a private root password on this host or group of hosts:

	I request a private `root` password. (Please explain why `sudo ALL` is not adequate in the Additional Information field.)
	I need to know (or already know) this private `root` password.
	I do not need a private `root` password.

Agreement on Sharing Responsibility for this Host

Yes No	I agree to use reasonable precautions and abide by SCS policies to guard the passwords of any accounts with superuser privileges from unauthorized use.
Yes No	I agree not to share any other superuser privileges (e.g., via `sudo`) except with individuals who have also agreed to and submitted this form.
Yes No	I agree to maintain a reasonable degree of security on the host, as determined by SCS.
Yes No	I agree to periodic security scans by the SCS Security Team, and to comply promptly with requests to remove vulnerabilities.
Yes No	I agree to abide by the rules described below for local account management.
Yes No	I understand that my superuser privileges do not excuse me from abiding by SLAC's policy on Use of SLAC Information Resources, in particular with respect to access to confidential information.

Taylor

	Please install Taylor.
	Taylor is already installed.

NFS Access

	Please give this host or group of hosts access to SLAC's central NFS fileservers.
	This host or group of hosts does not need access to SLAC's central NFS fileservers.
	This host or group of hosts already has access to SLAC's central NFS fileservers.

I am submitting this form to notify SCS that I already have superuser privileges on the specified host(s); I do not need any action by SCS.

Additional information (optional):

If you agree to make a conscientious, good-faith effort to abide by the spirit of the above requirements, press this button to send this form to SCS.

Notes

The following notes are intended to clarify and elaborate some of the specific points in the agreement above.

Guarding Passwords

You should guard the secrecy of all passwords, especially those with super user privileges.

You must change privileged passwords at least every 6 months.
You must choose good-quality passwords according to SLAC guidelines.
You must not share your personal password with anyone, and you may only share the root password for a system with other individuals who have agreed to and submitted this form.
You should avoid writing down passwords, speaking them in the presence of anyone not authorized to share the password, or allowing others to look over your shoulder when typing them.

Maintain Security

You must maintain the system with a reasonable degree of security, as determined by SCS. This requirement may include 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.

Taylor automates many routine security measures. However, some tasks (e.g., those requiring a reboot) cannot be completely automated. Every user with superuser privileges for a system has an affirmative responsibility to maintain the security of that system.

Installing Taylor

If SCS has never before been given any superuser privileges on your system, you may need to do the initial Taylor installation yourself. Please indicate if this is the case in the Additional Information field and we will send you instructions.

Local Account Rules

Taylor normally sets up your machine to run NIS. there is a taylor option to turn off NIS in some special situations, but we strongly recommend that you run NIS and use our NIS passwd and group files to define all or most of the accounts needed on your machine. Warning: you should be aware that the rules described in this section, if conscientiously applied on all client machines, should protect files owned by accounts in NIS, but will do nothing at all to protect any files on the server owned by local accounts on the various clients.

Note that it is possible to restrict access to your machine to a subset of the accounts or groups in NIS. It is also possible to override some, though not all, fields from the NIS entry for a particular account. However, if you do use our NIS 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 make any changes to the local passwd or group files you must obtain agreement from all of those with superuser privileges on the machine to all of the following requirements:

You must consult with SCS before changing any of the special-purpose low-numbered accounts or groups that are provided by the OS vendor.
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.)
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 satisfy one or the other of the following requirements.
- The local account or group must 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 or groups in our NIS databases. To insure that UIDs and GIDs will never conflict, we require you to use numbers in the range 20,000 to 39,999, inclusive.
- The local account or group must duplicate both the name and the number of the corresponding entry in our NIS databases; it must be associated with the same individual or SLAC organizational unit as the NIS entry; and in the case of an account, it must also specify compatible UNIX group information. This last requirement 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 NIS group as the primary group of the NIS account. It is permitted to add such local accounts to additional local secondary groups.
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.

Contact Information:

Security policies: security@slac.stanford.edu
UNIX system administration: unix-admin@slac.stanford.edu

Len Moss