Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #212148 > unrolled thread

Early mainframe security

Back to article view | Back to alt.folklore.computers

Contents

  Early mainframe security antispam@math.uni.wroc.pl - 2020-06-29 20:40 +0000
    Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 13:49 -0700
    Re: Early mainframe security Dan Espen <dan1espen@gmail.com> - 2020-06-29 16:53 -0400
      Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-29 23:59 +0000
        Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 17:24 -0700
          Re: Early mainframe security Thomas Koenig <tkoenig@netcologne.de> - 2020-06-30 07:57 +0000
          Re: Early mainframe security "Kerr-Mudd,John" <notsaying@invalid.org> - 2020-06-30 08:21 +0000
    Re: Early mainframe security Douglas Miller <durgadas311@gmail.com> - 2020-06-29 13:55 -0700
      Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-29 17:40 -0400
      Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-06-30 00:08 +0000
        Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 07:38 -0700
          Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-01 15:14 +0000
            Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 13:03 -0700
              Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-02 00:52 +0000
                Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-11 18:04 -0700
                  Re: Early mainframe security Grant Taylor <gtaylor@tnetconsulting.net> - 2020-07-11 19:10 -0600
                  Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-07-12 02:50 +0000
                    Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-13 14:26 -0700
    Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-29 23:00 +0100
      Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-30 00:27 +0000
        Re: Early mainframe security and channel programs John Levine <johnl@taugh.com> - 2020-06-30 02:58 +0000
        Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 11:34 +0100
        Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-30 06:15 -0700
          Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-30 14:01 +0000
            Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 22:39 +0100
        Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-06-30 19:37 -0500
    Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-06-29 22:18 +0000
      Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 15:49 -0700
      Re: Early mainframe security Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-29 18:28 -0600
        Re: Early mainframe security Quadibloc <jsavard@ecn.ab.ca> - 2020-06-29 21:11 -0700
        Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 11:35 +0100
          Re: Early mainframe security Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-06-30 22:18 +0000
            Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-01 15:08 +0000
      Re: Early mainframe security Thomas Koenig <tkoenig@netcologne.de> - 2020-06-30 07:51 +0000
        Re: Early mainframe security Bob Eager <news0073@eager.cx> - 2020-06-30 08:49 +0000
    Re: Early mainframe security Ahem A Rivet's Shot <steveo@eircom.net> - 2020-06-30 09:43 +0100
    Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-06-30 19:23 -0500
      Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-30 18:03 -0700
        Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-30 22:32 -0400
          Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-07-01 03:21 +0000
            Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-30 23:52 -0400
            Re: Early mainframe security Dan Espen <dan1espen@gmail.com> - 2020-06-30 23:56 -0400
        Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-07-01 22:21 -0500
    Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 07:33 -0700
    Re: Early mainframe security Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-03 12:25 -1000
      Re: Early mainframe security Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-03 12:58 -1000

Page 3 of 3 — ← Prev page 1 2 [3]

#212179

On Wed, 1 Jul 2020 03:21:13 -0000 (UTC), John Levine <johnl@taugh.com>
wrote:

>In article <hbtnfflqu2nqedirnhhs30vh9ouu9ioa5k@4ax.com>,
>J. Clarke  <jclarke.873638@gmail.com> wrote:
>>>How much of a problem was this when the system was designed? Work on the
>>>360 goes back to the start of the 60s, if not back to the 50s. In those
>>>days computers were locked away and only staff had access, so I don’t think
>>>there were hackers. by 64 it was more of a problem.
>>
>>For certain values.  A crooked employee would still be a problem, just
>>easier to catch and less likely to get away with it.
>
>A crooked employee didn't need operating system security bugs. I'd
>think they'd do things like drop a few fake cards into the nightly
>accounting update run.

This is also true.  

[toc] | [prev] | [next] | [standalone]

#212180

John Levine <johnl@taugh.com> writes:

> In article <hbtnfflqu2nqedirnhhs30vh9ouu9ioa5k@4ax.com>,
> J. Clarke  <jclarke.873638@gmail.com> wrote:
>>>How much of a problem was this when the system was designed? Work on the
>>>360 goes back to the start of the 60s, if not back to the 50s. In those
>>>days computers were locked away and only staff had access, so I don’t think
>>>there were hackers. by 64 it was more of a problem.
>>
>>For certain values.  A crooked employee would still be a problem, just
>>easier to catch and less likely to get away with it.
>
> A crooked employee didn't need operating system security bugs. I'd
> think they'd do things like drop a few fake cards into the nightly
> accounting update run.

That was the kind of security that was used.
There was usually a document with totals that the cards had to match.
The detail runs were carefully checked.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#212188

Peter Flass wrote:

> Jon Elson <elson@pico-systems.com> wrote:

>> But the OS had
>> massive holes.  The biggest one was the system for enabling a callback on
>> a
>> program exception.  There was a system call SPIE (Specifiy Program
>> Interrupt Exit), and if an exception occurred, your specified exception
>> handler got
>> control with the PSW passed.  You could then change the PSW and return. 
>> The default OS 360/MFT and /MVT supervisor calls for this allowed you to
>> clear the P bit (problem state, meaning user program) and return, putting
>> your
>> program into supervisor mode!  AMAZING!  But, nobody at IBM ever thought
>> of computer hackers.
> 
> How much of a problem was this when the system was designed? Work on the
> 360 goes back to the start of the 60s, if not back to the 50s. In those
> days computers were locked away and only staff had access, so I don’t
> think there were hackers. by 64 it was more of a problem.
Well, I doubt the OS/360 team had thought of a bunch of college kids being 
let loose on a 360 in 1962/63.  But, that was sure what happened around 1969 
or so.

Jon

[toc] | [prev] | [next] | [standalone]

#212182

On Monday, June 29, 2020 at 4:40:49 PM UTC-4, anti...@math.uni.wroc.pl wrote:
> I wonder how much security was provided on early IBM mainframes.
> IIUC 360 series had distinction between supervisor and user (poblem
> state) mode and used key memory protection.  This in principle
> allows good security.  OTOH key protection was optional on
> low end models, so it seems that security there has based
> on honesty of personel.  Looking at MVS documentation it
> is mentioned that program may have right to access to whole
> disc, but apparently there were no way to restrict access
> to part of disc.  More generaly, IIUC access methods passed
> channel program to nucleus and I see no place where access
> was checked.  So, could badly behaving program write on the
> whole disc, or there were some safeguard that I missed?
> 
> -- 
>                               Waldek Hebisch

The only access to an IBM system I had (ignoring my intro to a System/3) was through a teletype.  That was handled by running VM/370 and giving the teletype access to a VM running CMS.  In theory, great security since you are in an isolated VM.  Somehow a fellow student managed to break out of it anyway...

     - Tim

[toc] | [prev] | [next] | [standalone]

#212530

Within a year of taking two semester hr intro to computers/fortran, I
was hired fulltime by the univ to be responsible for mainframe
systems. Last week some of the people came out from the science center
to install CP67. I rewrote lot of the code and sometimes IBM would
suggest things to rewrite ... in retrospect, some of the suggestions
could have originated with gov. agencies ... I didn't learn about these
guys until much later (gone 404, but lives on at wayback machine).
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

When I graduate, I join the science center. The science center had
ported APL\360 to CP67/CMS as CMS\APL ... had to redo the storage
management and garbage collection for large demand page virtual memory
... also added API to systems services (like file read/write)
... enabling lots of real-world applications.

One of the remote online CMS\APL early users were the business planners
in Armonk corporate hdqtrs that installed the most holiest of corporate
assets on the cambridge system (detailed customer information) to do
business modeling. We had to demonstrate a very high level of security
since the system also had profs, staff, and students online users from
some of the univ. in the boston/cambridge area.

Then company got a new CSO that had come from gov. service (at one time
head of presidential detail) and I got asked to run around with him and
talk about computer security (while a little bit of physical security
rubs off on me).

there is MVS folklore about one of the agencies looking at installing
MVS ... but before they wanted the "exact" source for all the components
they would be running (for review). Company spent $5M investigating the
problem before deciding that it was practical.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#212531

some of the CTSS people had gone to the 5th flr to do Multics and others
went to the science center and did virtual machines, the internal
network (technology also used for the corporate sponsored BITNET),
invented GML in 1969, bunch of online stuff. Somewhat as a result, there
was a little friendly rivalry between the 4th and 5th flrs.

One area the gov. and military installation
https://www.multicians.org/sites.html
including
https://www.multicians.org/site-afdsc.html

spring 1979, got a call that some AFDS people wanted to come by to talk
about getting 20 vm/4341 ... they never made it to fall 1979 ... at
which time it had grown 210 (distributed) vm/4341s (large customers
started ordering hundreds of vm/4341s at a time, sort of the leading ege
of the coming distributed computing tsunami). archived multics posting
with old email
http://www.garlic.com/~lynn/2001m.html#email790404
archived afc posting with same old email
http://www.garlic.com/~lynn/2001m.html#email790404b

It had possibly started from early 1979 when I got con'ed into doing
some benchmarks on engineering 4341 for one of national labs (4341 had
yet to ship to customers) ... they were looking at getting 70 4341s for
a compute farm (sort of the leading edge of the coming cluster
supercomputing tsunami).  old archived afc posts with some of benchmark
http://www.garlic.com/~lynn/2000d.html#0

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | alt.folklore.computers

csiph-web