UNIX System Administration Handbook - Evi Nemeth [478]
This incident illustrates a problem that is obvious with hindsight and also hard to fix. Whose responsibility is the data on a broken disk? It cannot always be wiped before being returned for repair. Service providers (and probably more importantly, peripheral resellers) do not necessarily see your data as valuable; they see only a broken or breaking disk.
As sysadmins, we are used to protecting our backup tapes. Broken disks are taken for granted, and they shouldn’t be. Whenever possible, a disk with valuable data should be wiped (a low-level format and verify should do it) before being returned for repair or trade-in. If it’s too broken to reformat, make sure your service provider knows that it contains sensitive data that you would like deleted. Consider putting statements about your data in the contract with a repair service provider.
It is probably worthwhile to ask your service providers about their policy regarding customers’ data. When they admit that they don’t have one, act very surprised and shocked.
High-security U.S. government sites (defense installations, especially) are sometimes forbidden to let any computer equipment off-site, ever. If it breaks, they have to buy a new one. It may sound paranoid, but as this story illustrates, it is not without basis. (The policy even applies to components such as CPU boards that wouldn’t normally retain data.)
Bill must die!
A student left himself logged in on a machine in the computer science undergraduate lab when he went to his TA’s office to pick up a document. While he was gone, someone typed in a mail message to president@whitehouse.gov that made death threats against then-President Clinton. The Secret Service called the next morning.
The student was a foreigner who had served in his country’s militia as an encryption expert. He had also neglected to mention to the local system administrators that he received an acknowledgment from the White House for mail he had not sent. Things did not look good.
The system administrators spent the weekend collecting log files and card access records to determine what had happened. Luckily, the log files provided enough circumstantial evidence to convince the Secret Service that the student had probably been the victim of a prank.
The student’s command history file (~/.history , which included timestamps) verified that he was a regular user of pine . But the offending message had been sent with mail , with a sizable period of inactivity before and after the event. Most users cling tenaciously to a single user agent for reading and writing mail, so the discrepancy was highly suggestive of a compromised account.
As it turns out, threatening the president of the United States is a felony. Even though the foreign student was exonerated, the Secret Service investigation continued. The event occurred a second time. It was again a forgery, but the log files gave us enough information to identify who we thought was sending the messages. We were never told by the Secret Service if they pursued the person whose name we gave to them.
We now recommend that students use xlock 6
when they leave their terminals unattended. We have modified xlock to log the user out after a period of inactivity so that students can’t hoard the good machines in the lab.
27.9 LOCALIZATION AND UPGRADES
Each site’s localization and upgrade scenarios are different. There is no one right way—the size of your site and the scope of the required upgrade dictate the appropriate policies and procedures. This section should really