• Choose a category
• All
• Classic-Fiction

• I will undertake to keep confidential any disclosure to me by the University of software (including methods or concepts used therein) licensed to the University for use on its computers and I hereby indemnify and hold harmless the University against claims of any nature arising from any disclosure on my part to another of the said software in breach of this undertaking.

• I undertake to maintain the highest standard of honesty and personal integrity in relation to my usage of the Department’s computing and network facilities. I further warrant that I will avoid any actions in relation to my usage of the Department’s computing or network facilities that may bring any disrepute upon the Department or the University.

I understand that I am bound by Regulation 8.1.R7 of the University of Melbourne (set out in the Student Diary), which also governs and regulates my use of University computing and network facilities.

I understand that acting in breach of any of the principles set out above will incur severe penalties including failure in an assignment or a subject, the suspension or withdrawal of access to University computing facilities, suspension or expulsion from the University, imposition of fines, and/or legal (Computer) Act 1988.2

Take special note of the weasel words about honesty, personal integrity, and not bringing the University into disrepute. Vague requirements such as these give you some room for later maneuvering and help to cover any specifics that may have been inadvertently left out of the policy. Although their true legal weight is probably negligible, it’s a good idea to include such requirements in your policy agreements.

Sysadmin policy agreements

A policy document for sysadmins (and others with special status) must set guidelines for using root privileges and for honoring users’ privacy. It is hard to respond to a user’s complaint that mail is broken without looking at messages that have bounced. But a copy of the headers is often sufficient to characterize and fix the problem.

If your site uses a tool such as sudo for root access, it is essential that your sysadmins use good passwords and not share their logins with anyone. Consider running crack on sysadmins’ passwords regularly. It’s also essential that they not execute sudo tcsh (token use of sudo ) because that defeats sudo ’s logging feature.

See page 41 for more information about sudo .

For some sysadmins, the urge to show off rootly powers overcomes common sense. Gently suggest other career alternatives.

At some sites, having the root password is a status symbol, perhaps more valuable than a key to the executive washroom. Often, the people that have the password are engineers that don’t need it or should not have it. One site we know offered all engineers the root password, but stipulated that any takers would have to wear a beeper and help others when necessary. Requests plummeted.

Another technique that we have used with good success is to seal the root password in an envelope and hide it in a spot known to the sysadmin staff. Sysadmins generally use sudo to do their work; if they actually need the root password for some reason, they open the envelope. The root password is then changed and a new envelope is stashed. It’s not difficult to steam open an envelope, but only sysadmins have physical access to the hiding place, and we trust our staff to respect the system.

Policy and procedures for emergency situations

Decide ahead of time who will be in charge in the event of a security incident. Set up a chain of command and keep the names and phone numbers of the principals off-line. It may be that the best person to put in charge is a sysadmin from the trenches, not the IT director (who is usually a poor choice for this role).

We are accustomed to using the network to communicate and to access documents. However, these facilities may be unavailable or compromised after an incident. Store all the relevant contacts and procedures off-line. Know where