The Risks Digest, Volume 6, Issue94

Peter G. Neumann

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 6: Issue 94

Tuesday 31 May 1988

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
Info on RISKS (comp.risks)

The perceptions of novice MAC users

Mark Shand <munnari!cad.jmrc.eecs.unsw.oz.au!shand@uunet.UU.NET>

Mon, 23 May 88 16:43:51 EST

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.

Risk of carrying a bank card?

Robert C. Lehman <rcl@jolt.columbia.edu>

Tue, 31 May 88 17:39:52 EDT

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

Optimisers too tacit, perhaps?

J M Hicks <cudat@CU.WARWICK.AC.UK>

Fri, 27 May 88 10:53:23 +0100

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

Re: Federal "smart cards" (the "Australian Card" scheme)

Jon Jacky <jon@june.cs.washington.edu>

Fri, 27 May 88 09:12:15 PDT

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

national ID card constituency; and ...

Andrew Klossner <andrew%frip.gwd.tek.com@RELAY.CS.NET>

30 May 88 18:10:57 GMT

    "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.

Telco clerks, cellular phones, fire fighting

Andrew Klossner <andrew@tekecs.GWD.TEK.COM>

Mon May 30 11:02:58 PDT 1988

    "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.

Costs of 24-hr human attendants

<mnetor!utzoo!henry@uunet.UU.NET>

Fri, 27 May 88 17:48:06 EDT

> 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

Telecommunication Redundancy (Chris Maltby, RISKS-6.93)

Klaus Brunnstein <brunnstein%rz.informatik.uni-hamburg.dbp.de@RELAY.CS.NET>

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

Re: Down in the Dumps (a true story)

<dvk@SEI.CMU.EDU>

Tue, 31 May 88 11:41:22 EDT

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.

Report problems with the web pages to the maintainer