Privileged Access Policy

Privileged Access (i.e., root or root equivalents) for machines managed by CSD-CF are bestowed to those who need it via the sudo command (sudo is short for "SUperuser DO"). To use it, simply prefix the command you want to run as root with "sudo". For example:

sudo /sbin/reboot

sudo will ask you to authenticate yourself by typing in your password. sudo remembers your password for five minutes after the last sudo command you ran, so that you don't have to continually enter your password.

Why we use sudo instead of giving out the root password:

  • Root is all powerful.

    • In Unix and Unix-like systems, system administration privileges are all or nothing. A user either has root access or not, and root access implies complete control of a machine. If the machine in question is used by more than one person, or root has access to other systems or user files, it is more acceptable to give some users partial root privileges.

  • The root user can hide all of their actions.

    • sudo logs every command run via sudo. Having a record of what's being done with sudo helps us diagnose problems with individual systems/processes and general confiugration issues, as well as helping us identify needed improvements.

  • The root password gives you access to any command on a system.

    • Via its config file, sudo can give a user root access for particular set of commands. This also avoids the "all or nothing" effect, alllowing us to give individual users more control over their machines and to help themselves out of common problems.

Who can get sudo privileges?

  • Anyone who wants sudo privileges must first read and accept the terms set down by this policy.
  • "Systems" people - those who have traditionally performed systems administration duties, and are responsible for maintaining particular software applications or systems can have sudo privileges on some CS systems upon request.
  • Faculty can have sudo privileges on all computers that belong to them upon request.
  • Visiting faculty, staff, students, and post-docs with a legitimate need for privileged access can get sudo privileges on their personal desktops upon request.
  • All others may get sudo privileges with sufficient justification.

On what systems can you get sudo privileges?

  • Personal workstations - Privileged access to a general purpose research workstation may be granted to specific users of that workstation with a legitimate need for privileged access.
  • Research systems - Privileged access to computers designated for special-purpose research may be granted to users of those computers with a legitimate need for privileged access.
  • Privileged access will not be granted to any user on the following systems:
    • File servers.
    • Mail servers, or any servers holding mail for multiple users.
    • General-purpose multiuser computers.
    • Servers and infrastructure computers.

Do's and Don'ts of Privileged Access

  • Don't change the root password on your machine.

    • Don't change the password of any users, especially root. The only password you are responsible for, and the only password you are allowed to change is your own. Changing the root or any other password will result in loss of privileged access and possible termination of your account.

  • Don't add user accounts to the system.

    • Access to computer systems in the Computer Science Department are controlled exclusively by CSD-CF.

  • Don't grant sudo access to any user.

    • Being granted privileged access to a machine does not entitle you to grant the same access to others. Anyone who needs such access must request it from the system administrators. Granting privileged access to others will result in loss of privileged access and possible termination of your account.

  • Choose an extrordinary password for your personal account.

    • This is especially important because your password can be used to exercise certain root privileges.

    For similar reasons, we expect anyone who accepts these privileges to take extrodinary care in protecting their password. Never send your password in the clear over the network (change your password immediately should you do this). Never email your password. Never share your password with anybody.

  • Don't run network daemons: i.e. no ircd, no ftpd

    • If you think you need to run a network service, please talk with a system administrator.

  • Don't use sudo to run a shell: e.g. "sudo bash", or to just become root via "su".

    • We know it's a small additional burden to have to prefix each command with "sudo", but we, the systems adminstrators, would like to keep a handle on what people are doing to their systems so that chaos does not take over the department.

    It is much easier to diagnose a problem if we know what has been done to a machine to create (or attempt to address) a problem. Similarly, it is much easier for us to understand how you cleverly solved some problem if we have a record of the actions you performed.

    We use sudo, too. Log trails are an important part of enabling multiple people to manage the complexities of a large system.

  • Don't use sudo to "su" to another user.

    • It is a violation of Department and University policy to use the account of another user. Doing so will result in the loss of your privileged access and possible termination of your account.

  • If you make changes to your system, write down what you did.

    • Not for us; for yourself. The configuration of Linux systems in CS is constantly evolving. We will have to reinstall the OS on your system from time to time, although we will try to keep such reinstalls to a minimum.

    Our official policy is that all machines should be able to be rebuilt using our automated kickstart process at any point in time. CSD-CF should be aware of any specific customizations made on a machine, to ensure your changes needs survive OS reinstalls.

    If you want to make a change to your system configuration, please talk to the systems administrators first. We may have already provided a solution to the problem you are trying to solve. Also, what you want may be something we should be doing CS wide.

    Extrodinary user customization is not a valid excuse to defer or forgo an OS upgrade when it becomes available.

  • If you royally mess up your system, you're on your own.

    • The only thing we will do is reinstall the OS.

    If you mess up your system in a small way, we may help you repair it at our discretion.

    If a system is compromised by your action, you will be held accountable for the results.

  • When in doubt, ask the system administrators.

    • If you're not absolutely sure of what you're doing, consult the system administrators. Doing so in encouraged, and saves everybody time.

If you have any questions about appropriate use of this privilege, please contact action@cs.