Acquiring Unsupported Hardware

Brown University Memorandum
Department of Computer Science

To: Faculty and administrators of non-sun equipment
From: FACIL
Date: May 10, 1994
Subject: Regulations pertaining to unsupported systems within the department

  1. Prior to Receipt

    1. FACIL approval before acquisition

      Before any computer system is ordered by a faculty member or a technical staff member, the facil committee must be notified. This committee will access the need and impact on the department and will elect to allow or disallow the acquisition. There are no exceptions to this. Discussions should include what amounts, if any, of department money is to be spent for the acquisition, maintenance, and support of the system. Additionally, physical placement and power requirements should be addressed.
    2. Configuration

      While the basic configuration will have been discussed by facil, more specific discussions should take place with the technical staff prior to ordering to insure proper components are received. It should be noted that the technical staff's responsibility is purely advisory, representing the general computing interests of the department.
    3. Maintenance Issues

      Facil will have addressed the issue of whether the department will provide funds towards the maintenance of the system. Obtaining maintenance contracts (both software and hardware), maintaining records concerning these contracts, as well as their renewal are the sole responsibility of the faculty member acquiring the system. They are responsible for the vendor contact as well as managing all the paperwork associated with the maintenance of the system. This includes any associated licenses.
    4. Supplies

      Ordinarily supplies for departmental systems are charged to the research facilities support account (VAX). Whether this applies to specific unsupported systems will be determined by facil.
    5. Ordering

      In order to maintain accurate records, all system orders should be placed through the Administrative Assistant. She should be supplied with all the necessary information to create the purchase order. It is not her job to hand carry this order through purchasing nor to deal with salesman concerning an unsupported system.
  2. Shipping and Receiving

    1. Receiving Equipment

      All records concerning the department's systems will be maintained by the Administrative Assistant. The content and accuracy of these records are the responsibility of the faculty member acquiring the system. Packing slips should be given to Kathy to add to these records. It is also the responsibility of the faculty member to ensure the equipment is moved to the proper location and installed. The technical staff is not responsible for this.
    2. Inventory

      All inventory information concerning the system should be passed along to the Administrative Assistant. Again the accuracy of this information is the responsibility of the faculty member. Cooperation in maintaining accurate inventory records is appreciated.
  3. System Integration

    1. Contact Person

      While administrative responsibility for an unsupported system lies with the faculty member, the technical support for the equipment will usually fall to a student or students. The Department maintains strict guidelines regarding student management of equipment since it enables extraordinary priviledge and consequent security risks within the network. All users of the equipment must be aware of this support situation and should address questions and problems to the appropriate people, not the technical staff. Both the faculty member and the contact person should interact with the technical staff for any necessary information sharing.
    2. Root Password

      The root password should be known only to the responsible faculty member and the contact person. A record should be kept of all users having root access. Since root access on an unsupported system provides a very large security hole in our environment, people with this ability should be kept to the absolute minimum. Records of those users with the root password will be kept by the Administrative Assistant in the appropriate system database.
    3. Access to supported files on Suns

      Under certain conditions, the unsupported system will be added to the /etc/exports file on the servers, allowing mounting of user partitions (see section III.F.). The host files and name servers will also be updated. This priviledge can be granted only to those systems whose administrators or users with the root password are graduate students who have completed all degree related coursework and the comprehensive exams.
    4. Review prior to connect time

      A member of tstaff will meet with the system contact to review system configuration before it is connected to the department's ethernet. At this point all of the above should have been completed. Hostnames and IP numbers will be exchanged at this time.
    5. Network Connection

      All unsupported systems will exist on their own subnet allowing immediate and easy removal from the department network in case of network related problems.
    6. Administration and security

      As a person responsible for one or more unsupported machines, you agree to the following rules as a prerequisite to having your system(s) connected to the CS Department network. Note that we consider machines to be in two categories - those which NFS mount the CS servers, and those which don't. NFS access to the servers needs to be justified, because it increases the amount of exposure to security breaches that our servers have.
      1. First, here is a list of guidelines for everyone administering one or more unsupported machines, whether Sun filesystems are exported to them or not:
        1. We need to have root access to every system. To do this, you need to set up an "lroot" account with user-id 0, then let us set the password.You may have root access via the "root" account with your own root password.
        2. Subscribe to the newsgroup "brown.cs.unsupported", which is how we get in touch with you when needed.
        3. The system should have a /etc/motd file stating to whom problems should be reported.
        4. The /.rhosts and /etc/hosts.equiv files should be nonexistent, or only contain names of Brown CS Systems.
        5. No network "snooping" (packet monitoring) should be done on the system.
        6. The system should be kept "reasonably" secure - that is care should be taken to insure that the system conforms to the CS system use guidelines. Accounts must be limited only to Brown CS employees and CS students. For machines which have NFS access to the servers, no accounts will be created separately on these systems. That is, users must have a CS-wide account or none at all. There should be no shared-access accounts, no anonymous ftp accounts, no non-password accounts, and no easy ways to gain root access without the password.
        7. Monitor these aspects of your systems:
          • repeated login failures
          • su failures or successes
          • setuid programs
          • .rhost files
          • system executable changes (found via checksumming)
          • easily guessable passwords (routinely attempt to crack passwords)
          • monitor /var/adm/messages (or the equivalent)
          • port and run COPS (if possible)
      2. Here are the root password guidelines. We take these very seriously.
        1. Use your root authority sparingly and responsibly.
        2. Limit root access to the systems. If you must give someone else root access, send mail to "tstaff" informing us of the person and the reason.
        3. Don't use emacs when you are root. It has too many possibilities for security holes.
        4. Don't type the root password over a network connection from outside of Brown CS unless you really need to. If you do use the root password, change it immediately on your return. It is much safer to enter a password via modem connection than via Internet connection.
        5. You can do lots of damage as root. You can also go to jail for just using root to gain access to private data. Some actions are, in fact, felonious. Use the root password to manage the system, but not to access user data you couldn't access with your own user-id. In an emergency you may access user data local to your systems, but only with that user's permission.