While the old mainframes were too expensive for individual users, that changed 
by the 1960s and moreso by the 1970s. Reme4mber the Honeywell Kitchen Computer? 
The DEC PDP-5 and PDP-8?

As for mainframe security I don't believe that such operating systems as 
IBSYS/IBJOB cleared storage between jobs.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
Sent: Tuesday, May 7, 2019 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

When I explain mainframe security to the unwashed but curious, I cite history 
above all. The mainframe emerged from the primordial bit bucket soup at a time 
and in a form that utterly precluded individual users from possessing their own 
computers. The notion of one-computer-one-user was monstrously unthinkable. 
Mainframe was of necessity a shared environment in which utter strangers were 
obligated to breathe the same digital air and excrete into the same pools. 
Preventing cross contamination was the first commandment. This overriding 
concern guided and often dictated decades of evolution. There was never a 
moment in the mainframe's lineage where security or integrity could be 
architecturally compromised for *any* other goal.

Contrast that with any sort of Pee-Cee, where Pee stood originally for 'be sure 
to close the dorm room door when you toddle down the hall for a cold one'. 
Likewise for the U of xNIX. Each machine had one devoted owner whose needs were 
paramount. Unfortunately the computer could not discern its master by nose, a 
simple trick any dog could perform instinctively.

Then the throwable machines, by virtue of price and availability, were ushered 
on to the big-boy stage, and shareability was suddenly de rigueur. So began 
still-developing Rube Goldberg mechanisms to keep multiple users out of each 
other's shorts. After decades of flailing around, the only 'security tool' 
trusted by weenie-ware folks with something important to protect is server 
isolation. Let's be clear. The major reason for the mind-boggling proliferation 
of midrange servers is not the need for more MIPS and gigabytes. It's the 
fundamental distrust common to all non-mainframe users that anyone else allowed 
onto MY hardware is a potential mugger. One app, one server. You got a problem 
with that? The boss will buy you your own server.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tom 
Brennan
Sent: Tuesday, May 7, 2019 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: mainframe hacking "success stories"?

On the flip side, I bet there are many folks who were prompted to check their 
systems when they saw Phil Young's "Soldier of Fortran" web pages.

On 5/7/2019 7:49 AM, Nightwatch RenBand wrote:
> Publishing "success stories" is a two edged sword.  Don't and other
> installations cannot protect against the attach. Do and you spread the
> idea among the bad guys.
> It would seem that the best solution is:
> 1) Only discuss with people who have clearances and a "need to know",
> 2) Come up with a fix immediately
> 3) Put the fix in required maintenance and require that installations
> stay current.  Never mention what is in the fix.
> Of course this great power to the vendor comes with great responsibility.
> (thanks, Stan Lee)


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to