RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (06/01/88)
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
************************
-------