Text File

RISKS-LIST: RISKS-FORUM Digest Tuesday 31 May 1988 Volume 6 : Issue 94

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: The perceptions of novice MAC users (Mark Shand) Risk of carrying a bank card? (Robert C. Lehman) Optimisers too tacit, perhaps? (J M Hicks) Re: Federal "smart cards" (the "Australian Card" scheme) (Jon Jacky) National ID card constituency (Andrew Klossner) Telco clerks, cellular phones, fire fighting (Andrew Klossner) Costs of 24-hr human attendants (Henry Spencer) Telecommunication Redundancy (Klaus Brunnstein) Re: Down in the Dumps (dvk)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, ftp kl.sri.com, get stripe:<risks>risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

----------------------------------------------------------------------

Date: Mon, 23 May 88 16:43:51 EST From: munnari!cad.jmrc.eecs.unsw.oz.au!shand@uunet.UU.NET (Mark Shand) Subject: The perceptions of novice MAC users

At a dinner table conversation last Saturday night, the conversation turned Apple Macintoshes. One novice user exclaimed how confusing the error messages can sometimes be. She explained that the first time she'd crashed her MAC and saw the dialog box containing the bomb icon she'd rushed out of the room, fearing an imminent explosion. "It was the little sparks coming from the wick of the bomb that really convinced me of the danger."

I doubt WYSIWYG was meant to be interpreted so literally.

------------------------------

Date: Tue, 31 May 88 17:39:52 EDT From: Robert C. Lehman <rcl@jolt.columbia.edu> Subject: Risk of carrying a bank card?

The era of the-24 hour electronic bank teller seems to introduced a new twist into robberies. According to various news stories appearing in New York newspapers today, the body of a 66-year old doctor, Dr. Esther Lim, was found in Brooklyn. An article in today's New York Newsday by Bob Liff quotes an unidentified ranking police investigator as saying, "She was serverely beaten over a period of time. It appears that they were trying to get information out of her. We're looking at the assumption that it was the secret code to her bank account."

The article goes on to say, "Investigators suspect that the two men had staked out the money machine and picked out Lim as a target for robbery, thinking she had more than the $50 that bank records revealed she had withdrawn."

"They may have attempted to take the [ATM] code fom her," [Police Captain] Flinn said. "She only had $50. Obviously you can get a lot more money than that from the bank."

Robert Lehman, Columbia University

------------------------------

Date: Fri, 27 May 88 10:53:23 +0100 From: J M Hicks <cudat@CU.WARWICK.AC.UK> Return-Path: <@CORNELLC.CCS.CORNELL.EDU:cudat@CU.WARWICK.AC.UK> Subject: Optimisers too tacit, perhaps?

Some time ago, there was a discussion in this forum about changes being made without anyone being told, e.g. floating-point arithmetic being done by software instead of in hardware if the floating-point hardware is broken.

Optimising compilers often make very clever changes to the object code they produce in order to make the compiled code faster or smaller. One common optimisation which makes the code smaller is to remove unreachable code. Has anyone wished that the optimiser had told him/her that a large chunk of a program was unreachable when the fact that it was unreachable was due to a fault in the program?

Does anyone wish optimisers were more forthcoming about the changes they make?

J. M. Hicks (a.k.a. Hilary), Computing Services, Warwick University, Coventry, England. CV4 7AL

------------------------------

Date: Fri, 27 May 88 09:12:15 PDT From: jon@june.cs.washington.edu (Jon Jacky) Subject: Re: Federal "smart cards" (the "Australian Card" scheme)

Australia recently flirted with, then dropped, an idea something like this. The card itself was not to be "smart," at least not at first, but was supposed to be a general identifier to be used in most interactions between individuals and government. The "Australian Card" scheme got as far as a publicity campaign run by an advertising agency, with glossy brochures and mocked-up cards for the press. The Australian Senate killed the scheme. The story is told in Roger Clarke, "Just Another Piece of Plastic For Your Wallet: The 'Australian Card' Scheme," COMPUTERS AND SOCIETY 18(1) 7-21, Jan. 1988. COMPUTERS AND SOCIETY is the journal of the ACM SIG on Computers and Society (ACM/SIGCAS). - Jonathan Jacky, University of Washington

------------------------------

Date: 30 May 88 18:10:57 GMT Return-Path: <@RELAY.CS.NET:andrew%tekecs.gwd.tek.com@tektronix.tek.com> From: Andrew Klossner <andrew%frip.gwd.tek.com@RELAY.CS.NET> Subject: national ID card constituency; and ... Sender: andrew%tekecs.tek.com@RELAY.CS.NET Organization: Tektronix, Wilsonville, Oregon

"So far there has been no real rationale for Congress to consider [a national identity card], but the recent immigration law, which imposes fines on employers for hiring undocumented workers, will create a nation-wide constituency pressing for some reliable form of citizenship identification."

If an employer has made a reasonable effort to verify an applicant's right to work (birth certificate or I-9 form), they are in no danger if the applicant turns out to have used forged documents. This just happened in Oregon; an African national was hauled off from his janitorial job for using a forged I-9 (he faces a possible *20 years* in prison) and nothing happened to the employer. Under current law, employers have no strong need to see a national identity card, so I don't think this nationwide constituency will form.

------------------------------

Date: Mon May 30 11:02:58 PDT 1988 From: andrew@tekecs.GWD.TEK.COM (Andrew Klossner) Subject: Telco clerks, cellular phones, fire fighting

"Imagine if you will, a clerk on the premises Sunday afternoon. He is only paid $30,000 a year or so, and an alarm is noted on his console or terminal. He picks up a hand held cellular phone, walks into the room down the hall, sees smoke and grabs the Halon cannister from the wall. On the phone he dials 911 to tell them. He starts spraying the Halon, and likely gets the fire out before the firemen arrive. Then he calls a couple other numbers on the phone to key employees to get the word out: get over here fast."

Now imagine another scenario. The clerk dials 911 but nothing happens; cellular service has already been disrupted by the fire (as in fact it eventually was at Hinsdale). A ceiling caves in, or she's overcome by toxic fumes, and she succumbs. A few months later, her family files a multi-zillion dollar lawsuit against the telco.

Proper disaster planning eschews best-case scenarios.

------------------------------

Date: Fri, 27 May 88 17:48:06 EDT From: mnetor!utzoo!henry@uunet.UU.NET Subject: Costs of 24-hr human attendants

> Even assuming a day shift at all offices, another 3 shifts are required > to cover the remainder of the week...

Actually it's worse than that. 4 shifts aren't quite enough for a 168-hour week, even before you allow for vacations, sick leave, and the inconvenient fact that humans need to sleep roughly the same 8 hours in every 24 and can't be rescheduled daily. The standard rule of thumb for all-hours jobs like police is that filling one 24-hour 7-day position requires hiring five full-time people.

Henry Spencer @ U of Toronto Zoology {ihnp4,decvax,uunet!mnetor}!utzoo!henry

------------------------------

Received: from relay2.cs.net by RELAY.CS.NET id ab20001; 31 May 88 10:12 EDT From: Klaus Brunnstein <brunnstein%rz.informatik.uni-hamburg.dbp.de@RELAY.CS.NET> Subject: Telecommunication Redundancy (Chris Maltby, RISKS-6.93)

In connection with the Hinsdale Fire discussion, Chris Maltby writes:

`What no-one is talking about ... is whether society (i.e. government) has a role in ensuring adequate redundancy in as important a strategic network as the telephone system. ... The decision to route all the trunks through the same building is ... a typical commercial decision.'

When analysing the missing redundancy in the (government department) `Deutsche Bundes-Post', I have severe doubts that government agencies provide less risky behaviour than commercially competing (and thus cost-minimizing) enterprises. It seems more probable that *big* organisations (of `society' or as economically competing entities) behave less adaptive and thereby more risky than smaller, decentralised organisations.

The German lesson: our DATEX-P network (a packet-switched DATa EXchange system) has only on central communications controller per (usually metropolitan) area. Though dataflows may be re-routed between the node systems, intra-areal communication as well as entry into and exit from such an area is *controlled by a single control system*. Despite many discussions and arguments (of influential managers as well as computer security experts), the Post office managers argue that today, redundancy does not pay (a typical *commercial* argument). They simply hope (and wait) for better redundancy when ISDN services are implemented.

Apart from central control over large, well protected databanks, I think that decentralised systems provide for more effective, less expensive systems. Such an organisation is independent of `society' (and also of government organisation).

Klaus Brunnstein Univ.Hamburg Fed.Rep.Germany

------------------------------

Date: Tue, 31 May 88 11:41:22 EDT From: dvk@SEI.CMU.EDU Subject: Re: Down in the Dumps (a true story)

Unix is not friendly - let's face it. However, the true RISK is not in the unfriendliness, but in the wanton use of root privileges! Peter Rowell shows a wonderful (sorry about that) example of this.

Rule number 1: Don't use "root" unless ABSOLUTELY necessary. Rule number 2: When necessary, be DAMNED careful. Rule number 3: When the slightest bit in doubt, don't use "root".

Dumps should be run as "sys", or some other non-priv userID. Disks should be owned by "sys", and protected r--r--r--. This way, you can only write to them when you make a conscious decision to do so. When doing a restore, either manually change the protection on the SPECIFIC disk, or run as root (since root automatically gets write permission). However, "root" should only be used to restore (not to dump), and then only if you TRIPLE check your command line.

As to your specific problem - agreed, dump should check for bogus arguments. "/dev/rmtxx" should not have been accepted as a numeric argument. However, there are times when you want to dump TO a disk device (i.e. if you are dumping to a WORM device). Agreed, though, "default" disks and tape units should be eliminated, or at least configurable on a per-system basis.

However, you should not have been running as "root" in the first place. Far too many system administrators become enthralled with the power, and forget the RISKS. Most system administration tasks can be accomplished with a non-priv UID, with the system still being secure. Doing things from a non-priv account will cause some initial conversion headaches, but will save you from the BIG headaches when you make a small, 1 character error later on. In the cited example, the worst that would have happened would have been an error message "can't write to /dev/...", when dump failed to clobber your disk partition due to the file protection bits.

------------------------------

End of RISKS-FORUM Digest ************************