Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Early mainframe security
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Early mainframe security [message #396296] Mon, 29 June 2020 16:40 Go to next message
Anonymous
Karma:
Originally posted by: antispam

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
Re: Early mainframe security [message #396297 is a reply to message #396296] Mon, 29 June 2020 16:49 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
<antispam@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?
>

( From memory) MVS and OS/360 had control blocks called “Data Extent
Blocks” (DEBs) which were built when a file was opened containing
information on all the defined extents. A DASD channel program was checked
to make sure it was within the defined limits. A Seek Cylinder was (IIRC)
appended to the front for the requested cylinder, and then a “Set File
Mask” to prevent any other seeks in the channel program moving off that
cylinder.

--
Pete
Re: Early mainframe security [message #396298 is a reply to message #396296] Mon, 29 June 2020 16:53 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
antispam@math.uni.wroc.pl writes:

> 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?

Early mainframes had no way of communicating with the outside world
except in a locked room with cards and printing.
In DOS environments, the operator entered no passwords.

Online applications were few and far between.
They set up their own security but most often the few terminals were
also in secure areas.

--
Dan Espen
Re: Early mainframe security [message #396299 is a reply to message #396296] Mon, 29 June 2020 16:55 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Douglas Miller

On Monday, June 29, 2020 at 3:40:49 PM UTC-5, 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

I can't speak for the IBM 360, but in general things were done differently back then. Mainframes were not "online" like today, and thus not subject to all sorts of attacks. The harddisks were removable packs, aside from "drum memory" or a few others that were not "offline storage". And so the system was usually configured for the job(s) being run, and access to some other disk (or tape) media was physically impossible (nothing else was mounted). It was also much less likely that a malicious program could be run on a system, so it was really about preventing accidents. Memory protection was more for catching a buggy program quickly, and terminating it. As well as hopefully preventing damage to the "OS" (more of an executive/monitor than what we know as "OS" today). New/modified programs were tested using test datasets, so actual data loss was minimized. Most tape and harddisk drives have protection switches to prevent destruction of "system" data/programs, even intermediate datasets would be switched from unprotected to protected during the job.
Re: Early mainframe security [message #396302 is a reply to message #396299] Mon, 29 June 2020 17:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: J. Clarke

On Mon, 29 Jun 2020 13:55:25 -0700 (PDT), Douglas Miller
<durgadas311@gmail.com> wrote:

> On Monday, June 29, 2020 at 3:40:49 PM UTC-5, 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
>
> I can't speak for the IBM 360, but in general things were done differently back then. Mainframes were not "online" like today, and thus not subject to all sorts of attacks. The harddisks were removable packs, aside from "drum memory" or a few others that were not "offline storage". And so the system was usually configured for the job(s) being run, and access to some other disk (or tape) media was physically impossible (nothing else was mounted). It was also much less likely that a malicious program could be run on a system, so it was really about preventing accidents. Memory protection was more for catching a buggy program quickly, and terminating it. As well as hopefully preventing damage to the "OS" (more of an executive/monitor than what we know as "OS" today). New/modified programs were tested using test datasets, so actual data loss was minimized. Most tape and harddisk drives have protection switches to prevent destruction of "system" data/programs, even intermediate datasets
> would be switched from unprotected to protected during the job.

They were subject to attack once remote terminals were available.
There was a young man who I have met but whose name I cannot recall
now (Dean something or other perhaps?) who using a terminal installed
at his high school, some time in the late '60s or early '70s induced
the mainframe at the University of Florida to dump the entire list of
logins and passwords to every output device in the system. The upshot
of this was that after they finished yelling at him, the University of
Florida offered him a full ride through PhD if he wanted to go that
far as long as he (a) showed them what he did and (b) showed them how
to fix it so someone else could not do that, and IBM had a job waiting
for him whenever he decided that he was bored with school.
Re: Early mainframe security [message #396303 is a reply to message #396296] Mon, 29 June 2020 18:00 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: David Wade

On 29/06/2020 21:40, antispam@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?
>

Well lets start at the beginning. It was a totally different world.
A world where all data was double keyed to check its accuracy.
A world where there would be a strict schedule on which jobs ran.
A time when "the Operators" were gods and to whom you grovelled and
offered sacrifices when you wanted to test a program change...
.... but on April 1st you attempted to get revenge by changing the device
names round....

A world where on a small machine you only ran one or two jobs at once.
Where there were no fixed disks. A typical pack was less than 20Mb.
So when running a job only needed tapes and disks were on the machine.

So if a disk was corrupted it was instantly obvious which program had
done it, and as each program had a single keeper you were pretty sure
who was to blame.

Could you overwrite a whole disk? Generally it was hard.
The JCL specified files names and maximum file sizes.
If you have protection the access methods run in supervisor state so
can't be tampered with by a program. The program passes logical requests
read/write records or blocks to the access method, so the program can
only access the files allocated in the JCL. Once the space allocated is
filled the program abends.

Yes you could allocate a whole disk in JCL, but the JCL was generally
securely managed and change controlled.

Dave
Re: Early mainframe security [message #396304 is a reply to message #396296] Mon, 29 June 2020 18:18 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
In article <rddjkg$ffe$1@z-news.wcss.wroc.pl> you write:
> I wonder how much security was provided on early IBM mainframes.

Plenty, via a lock on the door to the computer room.

The user/supervisor security in OS/360 was intended to keep programs
from accidentally smashing the operating system or other programs, not
to keep determined intruders out. There was a well known two-line
Fortran program that would reliably crash OS/360 in the early 1970s,
and we all knew not to do that since it'd just make it take longer
until we got our printouts back.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Early mainframe security [message #396305 is a reply to message #396304] Mon, 29 June 2020 18:49 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
John Levine <johnl@taugh.com> wrote:
> In article <rddjkg$ffe$1@z-news.wcss.wroc.pl> you write:
>> I wonder how much security was provided on early IBM mainframes.
>
> Plenty, via a lock on the door to the computer room.
>
> The user/supervisor security in OS/360 was intended to keep programs
> from accidentally smashing the operating system or other programs, not
> to keep determined intruders out. There was a well known two-line
> Fortran program that would reliably crash OS/360 in the early 1970s,
> and we all knew not to do that since it'd just make it take longer
> until we got our printouts back.
>

Plus, they’d track you down and possibly expel you, or at least cancel your
account.

--
Pete
Re: Early mainframe security [message #396307 is a reply to message #396298] Mon, 29 June 2020 19:59 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: antispam

Dan Espen <dan1espen@gmail.com> wrote:
> antispam@math.uni.wroc.pl writes:
>
>> 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?
>
> Early mainframes had no way of communicating with the outside world
> except in a locked room with cards and printing.
> In DOS environments, the operator entered no passwords.
>
> Online applications were few and far between.
> They set up their own security but most often the few terminals were
> also in secure areas.

Well, I remember how it worked in Techical University in Wroclaw.
Basicaly anybody could come to computing center and give a file
of punched cards to operator. Next day one would get printout
with results. IIRC one was supposed to attach piece of paper
with name to the cards, but this paper was only used to give
back printout to correct person. Probably the only thing that
mattered for execution of program were proper accounting cards
at start of job. This was in 1982, but hardware were compatible
with old ICL 1900 and software were essentially from 1969/1970.
It is likely that operating procedures in western countries in
1970 would be the same.

I understand that in small commercial installation there
were small team of trusted people operating the machine
and no need for extra technical measures. But in bigger
installations probably more persons had means to submit
program and value of information was bigger.

More to the point, IBM quite early introduced passwords and
various controls/restrictions. So it is interesting to
know how much was really enforced.

--
Waldek Hebisch
Re: Early mainframe security [message #396308 is a reply to message #396299] Mon, 29 June 2020 20:08 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Douglas Miller <durgadas311@gmail.com> writes:
> On Monday, June 29, 2020 at 3:40:49 PM UTC-5, anti...@math.uni.wroc.pl wrot=
> e:
>> 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?
>> =20
>> --=20
>> Waldek Hebisch
>
> I can't speak for the IBM 360, but in general things were done differently =
> back then. Mainframes were not "online" like today, and thus not subject to=
> all sorts of attacks. The harddisks were removable packs, aside from "drum=
> memory" or a few others that were not "offline storage". And so the system=
> was usually configured for the job(s) being run, and access to some other =
> disk (or tape) media was physically impossible (nothing else was mounted). =
> It was also much less likely that a malicious program could be run on a sys=
> tem, so it was really about preventing accidents. Memory protection was mor=
> e for catching a buggy program quickly, and terminating it. As well as hope=
> fully preventing damage to the "OS" (more of an executive/monitor than what=
> we know as "OS" today). New/modified programs were tested using test datas=
> ets, so actual data loss was minimized. Most tape and harddisk drives have =
> protection switches to prevent destruction of "system" data/programs, even =
> intermediate datasets would be switched from unprotected to protected durin=
> g the job.

The Burroughs mainframe MCP (Master Control Program) from the mid 1960's
provided the concept of named files in directories on various spinning media
including magnetic tape, drum, HPT disk and later removable packs.

It also provided a usercode based security system with 9 heirarchical
privilege levels controlling access to various MCP capabilities and
access control to both devices such as card readers as well as individual
files on disk or pack. Aside from the standard user and other permissions
(read/write) there was the concept of a guard file associated with a disk
file that contained fine-grained permissions (e.g. granting a particular
set of users access to the file by usercode).

Thus most card decks started with a LI (Login) card:

?LI 9895 FRED 33561

Where the usercode was 9895 (qn in EBCDIC), the password FRED and the
charge code for job accounting/chargeback was 33561.

Way ahead of the (much larger) competition.

And the infamous 'BO' (Black Out) MCP command that would overwrite 10
M, W and O characters on the operator console to provide a blacked out
space for entering the password. Later, on video terminals, only the
final sequence of 'M' characters was printed. Since the MCP ignored
any input character after the 'BO', one could enter on a video console
the command "BOOBS" and recieve the reply "MMMMMMMMM".
Re: Early mainframe security [message #396309 is a reply to message #396307] Mon, 29 June 2020 20:24 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
<antispam@math.uni.wroc.pl> wrote:
> Dan Espen <dan1espen@gmail.com> wrote:
>> antispam@math.uni.wroc.pl writes:
>>
>>> 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?
>>
>> Early mainframes had no way of communicating with the outside world
>> except in a locked room with cards and printing.
>> In DOS environments, the operator entered no passwords.
>>
>> Online applications were few and far between.
>> They set up their own security but most often the few terminals were
>> also in secure areas.
>
> Well, I remember how it worked in Techical University in Wroclaw.
> Basicaly anybody could come to computing center and give a file
> of punched cards to operator. Next day one would get printout
> with results. IIRC one was supposed to attach piece of paper
> with name to the cards, but this paper was only used to give
> back printout to correct person. Probably the only thing that
> mattered for execution of program were proper accounting cards
> at start of job. This was in 1982, but hardware were compatible
> with old ICL 1900 and software were essentially from 1969/1970.
> It is likely that operating procedures in western countries in
> 1970 would be the same.
>
> I understand that in small commercial installation there
> were small team of trusted people operating the machine
> and no need for extra technical measures. But in bigger
> installations probably more persons had means to submit
> program and value of information was bigger.
>
> More to the point, IBM quite early introduced passwords and
> various controls/restrictions. So it is interesting to
> know how much was really enforced.
>

In my experience no one ever used dataset passwords. I think they were
stored in the VTOC, and had to be entered by the operator when the dataset
was opened. A password that you’d give to the operator on a post-it-note
didn’t seem very secure to me.

RACF OTOH, was a very good security system.

--
Pete
Re: Early mainframe security [message #396310 is a reply to message #396303] Mon, 29 June 2020 20:27 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: antispam

David Wade <g4ugm@dave.invalid> wrote:
> On 29/06/2020 21:40, antispam@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?
>>
>
> Well lets start at the beginning. It was a totally different world.
> A world where all data was double keyed to check its accuracy.
> A world where there would be a strict schedule on which jobs ran.
> A time when "the Operators" were gods and to whom you grovelled and
> offered sacrifices when you wanted to test a program change...
> ... but on April 1st you attempted to get revenge by changing the device
> names round....
>
> A world where on a small machine you only ran one or two jobs at once.
> Where there were no fixed disks. A typical pack was less than 20Mb.
> So when running a job only needed tapes and disks were on the machine.
>
> So if a disk was corrupted it was instantly obvious which program had
> done it, and as each program had a single keeper you were pretty sure
> who was to blame.
>
> Could you overwrite a whole disk? Generally it was hard.
> The JCL specified files names and maximum file sizes.
> If you have protection the access methods run in supervisor state so
> can't be tampered with by a program. The program passes logical requests
> read/write records or blocks to the access method, so the program can
> only access the files allocated in the JCL. Once the space allocated is
> filled the program abends.

That is part I want to understand. It seems that access macros set
up control blocks in user space. So user could tamper those control
blocks in arbitrary way. It is not entirely clear to me how system
ensured that access method will do its job. IIUC access method
run outside of resident part of nucleus and it seems that it used
SVC to communicate with nucleus. IBM documentation writes a lot
about variouos options and their effects and about general rights but
seem to be quite careful to _not_ disclose the actual details where
checks are done and what is checked.

>
> Yes you could allocate a whole disk in JCL, but the JCL was generally
> securely managed and change controlled.

Hmm, IIUC to compile or assemble program one needs to submit
proper JCL. In fact, to do anything in batch jobs seem to
require JCL. So anybody with right to submit jobs (like
student doing programming exercises) may submit JCL. OTOH
is seems that not all JCL is equal, some has more rights...

--
Waldek Hebisch
Re: Early mainframe security [message #396311 is a reply to message #396304] Mon, 29 June 2020 20:28 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Grant Taylor

On 6/29/20 4:18 PM, John Levine wrote:
> There was a well known two-line Fortran program that would reliably
> crash OS/360 in the early 1970s,

Is it wrong that I'd like to try that on MVS 3.8j running in Hercules
emulator?



--
Grant. . . .
unix || die
Re: Early mainframe security and channel programs [message #396315 is a reply to message #396310] Mon, 29 June 2020 22:58 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
In article <rde0tn$n2b$1@z-news.wcss.wroc.pl>,
<antispam@math.uni.wroc.pl> wrote:
> That is part I want to understand. It seems that access macros set
> up control blocks in user space. So user could tamper those control
> blocks in arbitrary way. It is not entirely clear to me how system
> ensured that access method will do its job. IIUC access method
> run outside of resident part of nucleus and it seems that it used
> SVC to communicate with nucleus.

Yup. The access method wrote its own channel programs and passed them
to the supervisor to run. Of if you wanted, your application could do
an EXCP itself to run any channel program it wanted. Sounds pretty
dangerous, huh? Nope.

It wrote a litttle channel program of its own that did a "set file
mask" command and then jumped (TIC for transfer in channel) to your
program. The set file mask tells the channel what your channel program
is allowed to do, confining it to a particular cylinder or track. To
prevent stomping other programs, every 2K storage block had a four-bit
storage key, and each running program and each channel program also
had a storage key which had to match the key for any data it wrote
(and depending on settings, maybe also any data it read.)


--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Early mainframe security [message #396318 is a reply to message #396311] Tue, 30 June 2020 00:11 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Monday, June 29, 2020 at 6:27:50 PM UTC-6, Grant Taylor wrote:
> On 6/29/20 4:18 PM, John Levine wrote:
>> There was a well known two-line Fortran program that would reliably
>> crash OS/360 in the early 1970s,

> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules
> emulator?

But by the time IBM got to MVS, they probably would have fixed the bug.

John Savard
Re: Early mainframe security [message #396322 is a reply to message #396304] Tue, 30 June 2020 03:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Koenig

[x-post, followup back to a.f.c.]

John Levine <johnl@taugh.com> schrieb:
> There was a well known two-line
> Fortran program that would reliably crash OS/360 in the early 1970s,
> and we all knew not to do that since it'd just make it take longer
> until we got our printouts back.

Do you still have the source? :-)
Re: Early mainframe security [message #396323 is a reply to message #396309] Tue, 30 June 2020 03:57 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Koenig

Peter Flass <peter_flass@yahoo.com> schrieb:

> RACF OTOH, was a very good security system.

I broke that once, accidentally, at our university
mainframe.

Basically, somebody who had since left had written a program
to evaluate file quotas on a department by department basis.
That person had installed this program with appropriate privileges
(don't ask me how) to bypass RACF. When he left, he changed it
so it would no longer work in the foreground under TSO. However,
I submitted that command as as a batch job containing TSO commands,
and found that it did things that it should not have been able
to do.

Took me some time to convince the people at the computer center
that this was actually true. When they were convinced, I saw
a few rather pale faces...
Re: Early mainframe security [message #396324 is a reply to message #396309] Tue, 30 June 2020 04:21 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Kerr-Mudd,John

On Tue, 30 Jun 2020 00:24:48 GMT, Peter Flass <peter_flass@yahoo.com>
wrote:

> <antispam@math.uni.wroc.pl> wrote:
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> antispam@math.uni.wroc.pl writes:
[]
>>
>> More to the point, IBM quite early introduced passwords and
>> various controls/restrictions. So it is interesting to
>> know how much was really enforced.
>>
>
> In my experience no one ever used dataset passwords. I think they were
> stored in the VTOC, and had to be entered by the operator when the
> dataset was opened. A password that you’d give to the operator on a
> post-it-note didn’t seem very secure to me.
>
> RACF OTOH, was a very good security system.
>

RACF was a right pain; so yes.

--
Bah, and indeed, Humbug.
Re: Early mainframe security [message #396326 is a reply to message #396322] Tue, 30 June 2020 04:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Tue, 30 Jun 2020 07:51:28 +0000, Thomas Koenig wrote:

> [x-post, followup back to a.f.c.]
>
> John Levine <johnl@taugh.com> schrieb:
>> There was a well known two-line Fortran program that would reliably
>> crash OS/360 in the early 1970s,
>> and we all knew not to do that since it'd just make it take longer
>> until we got our printouts back.
>
> Do you still have the source? :-)

There was a very short FORTRAN program in the early 1980s that would
reliably crash our ICL 2960.

No matter what operating system it was running.



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: Early mainframe security [message #396327 is a reply to message #396296] Tue, 30 June 2020 04:43 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Mon, 29 Jun 2020 20:40:48 +0000 (UTC)
antispam@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

I have no details but at Cambridge the Titan was considered secure
and students were encouraged to attempt to break it - success was (we were
told) often rewarded with a job that involved closing the hole you used.

The Titan was replaced by a 370 (165 IIRC) after which students
were no longer encouraged to attempt to break it and were instead advised
that it was far to easy to be a challenge and was instead a nuisance that
would get your access revoked. I was told that the shortest known program
that would crash it was half a word long - I never verified that claim.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Re: Early mainframe security [message #396328 is a reply to message #396310] Tue, 30 June 2020 06:34 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: David Wade

On 30/06/2020 01:27, antispam@math.uni.wroc.pl wrote:
> David Wade <g4ugm@dave.invalid> wrote:
>> On 29/06/2020 21:40, antispam@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?
>>>
>>
>> Well lets start at the beginning. It was a totally different world.
>> A world where all data was double keyed to check its accuracy.
>> A world where there would be a strict schedule on which jobs ran.
>> A time when "the Operators" were gods and to whom you grovelled and
>> offered sacrifices when you wanted to test a program change...
>> ... but on April 1st you attempted to get revenge by changing the device
>> names round....
>>
>> A world where on a small machine you only ran one or two jobs at once.
>> Where there were no fixed disks. A typical pack was less than 20Mb.
>> So when running a job only needed tapes and disks were on the machine.
>>
>> So if a disk was corrupted it was instantly obvious which program had
>> done it, and as each program had a single keeper you were pretty sure
>> who was to blame.
>>
>> Could you overwrite a whole disk? Generally it was hard.
>> The JCL specified files names and maximum file sizes.
>> If you have protection the access methods run in supervisor state so
>> can't be tampered with by a program. The program passes logical requests
>> read/write records or blocks to the access method, so the program can
>> only access the files allocated in the JCL. Once the space allocated is
>> filled the program abends.
>
> That is part I want to understand. It seems that access macros set
> up control blocks in user space. So user could tamper those control
> blocks in arbitrary way. It is not entirely clear to me how system
> ensured that access method will do its job. IIUC access method
> run outside of resident part of nucleus and it seems that it used
> SVC to communicate with nucleus.

From what I remember Access Methods run in privileged mode outside user
space. Not in the nucleus but part of the supervisor. That way you can
add access methods.

The MVS file system was extremely complex for its time and supported
file sharing etc.

The DCB in user space is used to communicate with the Access Method. It
does not contain all the information needed to access the file, some of
that is maintained in supervisor space in supervisor control blocks.

In fact there is no physical information in a DCB. So when you issue an
"open" the access method creates


> IBM documentation writes a lot
> about variouos options and their effects and about general rights but
> seem to be quite careful to _not_ disclose the actual details where
> checks are done and what is checked.

Its all in the Program Logic Manuals.

>
>>
>> Yes you could allocate a whole disk in JCL, but the JCL was generally
>> securely managed and change controlled.
>
> Hmm, IIUC to compile or assemble program one needs to submit
> proper JCL. In fact, to do anything in batch jobs seem to
> require JCL. So anybody with right to submit jobs (like
> student doing programming exercises) may submit JCL. OTOH
> is seems that not all JCL is equal, some has more rights...
>

Most universities did not use MVS for student jobs. Once you get to
running student jobs you would have user names and passwords.

User names with rights to mount packs would have their passwords kept
secure.


Dave
Re: Early mainframe security [message #396329 is a reply to message #396311] Tue, 30 June 2020 06:35 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: David Wade

On 30/06/2020 01:28, Grant Taylor wrote:
> On 6/29/20 4:18 PM, John Levine wrote:
>> There was a well known two-line Fortran program that would reliably
>> crash OS/360 in the early 1970s,
>
> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules
> emulator?
>
>
>
You can crash most early operating systems by filling the spool or temp
space.

Dave
Re: Early mainframe security [message #396331 is a reply to message #396310] Tue, 30 June 2020 09:15 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
<antispam@math.uni.wroc.pl> wrote:
>
> That is part I want to understand. It seems that access macros set
> up control blocks in user space. So user could tamper those control
> blocks in arbitrary way.

No, the DEBs were in an area with the system key.

> It is not entirely clear to me how system
> ensured that access method will do its job.

As I said, the supervisor ensured that any user I/O operation was limited
to one cylinder at a time, verified and enforced by the hardware.

--
Pete
Re: Early mainframe security [message #396332 is a reply to message #396331] Tue, 30 June 2020 10:01 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: antispam

Peter Flass <peter_flass@yahoo.com> wrote:
> <antispam@math.uni.wroc.pl> wrote:
>>
>> That is part I want to understand. It seems that access macros set
>> up control blocks in user space. So user could tamper those control
>> blocks in arbitrary way.
>
> No, the DEBs were in an area with the system key.
>
>> It is not entirely clear to me how system
>> ensured that access method will do its job.
>
> As I said, the supervisor ensured that any user I/O operation was limited
> to one cylinder at a time, verified and enforced by the hardware.

Yes, thanks. What you (and David Wade) wrote explains this
part, without knowing about such limit it looked like a hole...

--
Waldek Hebisch
Re: Early mainframe security [message #396338 is a reply to message #396332] Tue, 30 June 2020 17:39 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: David Wade

On 30/06/2020 15:01, antispam@math.uni.wroc.pl wrote:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> <antispam@math.uni.wroc.pl> wrote:
>>>
>>> That is part I want to understand. It seems that access macros set
>>> up control blocks in user space. So user could tamper those control
>>> blocks in arbitrary way.
>>
>> No, the DEBs were in an area with the system key.
>>
>>> It is not entirely clear to me how system
>>> ensured that access method will do its job.
>>
>> As I said, the supervisor ensured that any user I/O operation was limited
>> to one cylinder at a time, verified and enforced by the hardware.
>
> Yes, thanks. What you (and David Wade) wrote explains this
> part, without knowing about such limit it looked like a hole...
>
There were security holes, sometimes installed by the local site. So
there might be "secret" SVCs that allowed you to issue arbitrary IOs to
any device or do other privileged actions without checks,

Then I well remember having some what heated arguments because I changed
the password from the default on the Customer Engineer account.

Sometimes I remember silly things. So I used to work on networking
software for VM. The machines were connected to the UK university X25
network so no fire walls, no address blocks. The software ran
privileged. It did this so if users submitted transfers with invalid
passwords it could reset the "bad password" count and it didn't killed.

Most sites just installed what I sent, so had I wished I could have
popped a back door in the software that could have done anything on the
system from my office.

However when things went wrong, they often refused to let me see the
main console, in case I did anything I shouldn't.......

Dave
Re: Early mainframe security [message #396339 is a reply to message #396329] Tue, 30 June 2020 18:18 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2020-06-30, David Wade <g4ugm@dave.invalid> wrote:

> On 30/06/2020 01:28, Grant Taylor wrote:
>
>> On 6/29/20 4:18 PM, John Levine wrote:
>>
>>> There was a well known two-line Fortran program that would reliably
>>> crash OS/360 in the early 1970s,
>>
>> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules
>> emulator?
>
> You can crash most early operating systems by filling the spool or temp
> space.

An early version of Univac's OS/3 had a unique way of reacting to a
filled spool file: it would wrap around, losing everything in the process.

They fixed that bug fairly quickly.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: Early mainframe security [message #396342 is a reply to message #396296] Tue, 30 June 2020 20:23 Go to previous messageGo to next message
Jon Elson is currently offline  Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
Senior Member
antispam@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.

Yes, the hardware had the ability to enforce some security. 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.

Jon
Re: Early mainframe security [message #396344 is a reply to message #396310] Tue, 30 June 2020 20:37 Go to previous messageGo to next message
Jon Elson is currently offline  Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
Senior Member
antispam@math.uni.wroc.pl wrote:


>
> That is part I want to understand. It seems that access macros set
> up control blocks in user space. So user could tamper those control
> blocks in arbitrary way. It is not entirely clear to me how system
> ensured that access method will do its job.
Anybody can write a channel program to do anything. But, to get it EXECUTED
by the channel, you have to call the Execute Channel Program Supervisor.
The access method can do this for you, or you can call it directly. The
channel program checks for access to things you should not have before
passing it on to be scheduled.

We had a tape recovery channel program that was hand-coded. There were some
sense switches on the mag tape control unit that were normally used for CE
diagnostic purposes, but the channel could read them and make branches
(Transfer In Channel) based on the switches. So, you mounted two tapes, the
OS gave you full access to the drives, and the channel program was started.
It then looped, reading blocks from the source tape to the destination tape.
When you saw it was retrying endlessly to read a block, you could flip one
of the sense switches to tell it to either copy the block with the errors or
to omit the block and continue. The downside of this is it totally locked
up not only the tape controller, but the entire channel the tape controller
was on. But, to recover a faulty tape, it was about the only quick and
dirty way to do it.

Jon
Re: Early mainframe security [message #396345 is a reply to message #396342] Tue, 30 June 2020 21:03 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Jon Elson <elson@pico-systems.com> wrote:
> antispam@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.
>
> Yes, the hardware had the ability to enforce some security. 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.

>
> Jon
>



--
Pete
Re: Early mainframe security [message #396346 is a reply to message #396345] Tue, 30 June 2020 22:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: J. Clarke

On Tue, 30 Jun 2020 18:03:54 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

> Jon Elson <elson@pico-systems.com> wrote:
>> antispam@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.
>>
>> Yes, the hardware had the ability to enforce some security. 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.

For certain values. A crooked employee would still be a problem, just
easier to catch and less likely to get away with it.
Re: Early mainframe security [message #396348 is a reply to message #396346] Tue, 30 June 2020 23:21 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
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.


--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Early mainframe security [message #396349 is a reply to message #396348] Tue, 30 June 2020 23:52 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: J. Clarke

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.
Re: Early mainframe security [message #396350 is a reply to message #396348] Tue, 30 June 2020 23:56 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
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
Re: Early mainframe security [message #396358 is a reply to message #396296] Wed, 01 July 2020 10:33 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: timcaffrey420

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
Re: Early mainframe security [message #396360 is a reply to message #396308] Wed, 01 July 2020 10:38 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: timcaffrey420

On Monday, June 29, 2020 at 8:08:47 PM UTC-4, Scott Lurndal wrote:
> Douglas Miller <durgadas311@gmail.com> writes:
>> On Monday, June 29, 2020 at 3:40:49 PM UTC-5, anti...@math.uni.wroc.pl wrot=
>> e:
>>> 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?
>>> =20
>>> --=20
>>> Waldek Hebisch
>>
>> I can't speak for the IBM 360, but in general things were done differently =
>> back then. Mainframes were not "online" like today, and thus not subject to=
>> all sorts of attacks. The harddisks were removable packs, aside from "drum=
>> memory" or a few others that were not "offline storage". And so the system=
>> was usually configured for the job(s) being run, and access to some other =
>> disk (or tape) media was physically impossible (nothing else was mounted). =
>> It was also much less likely that a malicious program could be run on a sys=
>> tem, so it was really about preventing accidents. Memory protection was mor=
>> e for catching a buggy program quickly, and terminating it. As well as hope=
>> fully preventing damage to the "OS" (more of an executive/monitor than what=
>> we know as "OS" today). New/modified programs were tested using test datas=
>> ets, so actual data loss was minimized. Most tape and harddisk drives have =
>> protection switches to prevent destruction of "system" data/programs, even =
>> intermediate datasets would be switched from unprotected to protected durin=
>> g the job.
>
> The Burroughs mainframe MCP (Master Control Program) from the mid 1960's
> provided the concept of named files in directories on various spinning media
> including magnetic tape, drum, HPT disk and later removable packs.
>
> It also provided a usercode based security system with 9 heirarchical
> privilege levels controlling access to various MCP capabilities and
> access control to both devices such as card readers as well as individual
> files on disk or pack. Aside from the standard user and other permissions
> (read/write) there was the concept of a guard file associated with a disk
> file that contained fine-grained permissions (e.g. granting a particular
> set of users access to the file by usercode).
>
> Thus most card decks started with a LI (Login) card:
>
> ?LI 9895 FRED 33561
>
> Where the usercode was 9895 (qn in EBCDIC), the password FRED and the
> charge code for job accounting/chargeback was 33561.
>
> Way ahead of the (much larger) competition.
>
> And the infamous 'BO' (Black Out) MCP command that would overwrite 10
> M, W and O characters on the operator console to provide a blacked out
> space for entering the password. Later, on video terminals, only the
> final sequence of 'M' characters was printed. Since the MCP ignored
> any input character after the 'BO', one could enter on a video console
> the command "BOOBS" and recieve the reply "MMMMMMMMM".

The CP3680 terminal front end (which mostly ran on Burroughs Medium systems,
but you could hook it up to an HP3000 as well) had pretty sophisticated security.

Every terminal had a security mask, and every user had one as well. When the user logged in the user's security mask was ANDed with the terminal security mask to determine what transactions were allowed, so if somebody got a "superuser" usercode/password they couldn't log in from a teller's terminal and have any more access than the teller's terminal allowed.

It was a fair amount of setup by the system admins, but well worth it if you were worried about security (sold a lot of these to banks).

- Tim
Re: Early mainframe security [message #396361 is a reply to message #396339] Wed, 01 July 2020 11:08 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2020-06-30, David Wade <g4ugm@dave.invalid> wrote:
>
>> On 30/06/2020 01:28, Grant Taylor wrote:
>>
>>> On 6/29/20 4:18 PM, John Levine wrote:
>>>
>>>> There was a well known two-line Fortran program that would reliably
>>>> crash OS/360 in the early 1970s,
>>>
>>> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules
>>> emulator?
>>
>> You can crash most early operating systems by filling the spool or temp
>> space.
>
> An early version of Univac's OS/3 had a unique way of reacting to a
> filled spool file: it would wrap around, losing everything in the process.

Burroughs systems would handle resource shortages by placing the job
in a wait state until the operator resolved the issue. A resource
shortage would never crash the MCP.
Re: Early mainframe security [message #396362 is a reply to message #396360] Wed, 01 July 2020 11:14 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
timcaffrey420@gmail.com writes:
> On Monday, June 29, 2020 at 8:08:47 PM UTC-4, Scott Lurndal wrote:
>> Douglas Miller <durgadas311@gmail.com> writes:
>>> On Monday, June 29, 2020 at 3:40:49 PM UTC-5, anti...@math.uni.wroc.pl w=
> rot=3D
>>> e:
>>>> I wonder how much security was provided on early IBM mainframes.

>> =20
>> The Burroughs mainframe MCP (Master Control Program) from the mid 1960's
>> provided the concept of named files in directories on various spinning me=
> dia
>> including magnetic tape, drum, HPT disk and later removable packs.
>> =20
>> It also provided a usercode based security system with 9 heirarchical
>> privilege levels controlling access to various MCP capabilities and
>> access control to both devices such as card readers as well as individual
>> files on disk or pack. Aside from the standard user and other permissio=
> ns
>> (read/write) there was the concept of a guard file associated with a disk
>> file that contained fine-grained permissions (e.g. granting a particular
>> set of users access to the file by usercode).
>> =20
>> Thus most card decks started with a LI (Login) card:
>> =20
>> ?LI 9895 FRED 33561
>> =20
>> Where the usercode was 9895 (qn in EBCDIC), the password FRED and the
>> charge code for job accounting/chargeback was 33561.
>> =20
>> Way ahead of the (much larger) competition.
>> =20
>> And the infamous 'BO' (Black Out) MCP command that would overwrite 10
>> M, W and O characters on the operator console to provide a blacked out
>> space for entering the password. Later, on video terminals, only the
>> final sequence of 'M' characters was printed. Since the MCP ignored
>> any input character after the 'BO', one could enter on a video console
>> the command "BOOBS" and recieve the reply "MMMMMMMMM".
>
> The CP3680 terminal front end (which mostly ran on Burroughs Medium systems=
> ,
> but you could hook it up to an HP3000 as well) had pretty sophisticated sec=
> urity.

The CP3680 was an HP-2000 under the skins, and was originally developed
by a customer; they used a magtape channel to connect it to the medium systems host.

>
> Every terminal had a security mask, and every user had one as well. When t=
> he user logged in the user's security mask was ANDed with the terminal secu=
> rity mask to determine what transactions were allowed, so if somebody got =
> a "superuser" usercode/password they couldn't log in from a teller's termin=
> al and have any more access than the teller's terminal allowed.
>
> It was a fair amount of setup by the system admins, but well worth it if yo=
> u were worried about security (sold a lot of these to banks).

I think the B974 and CP9500 also had similar feature sets, but we used
the B874s for production in the Pasadena plant and I don't recall if NDL
had those features nor not.
Re: Early mainframe security [message #396367 is a reply to message #396362] Wed, 01 July 2020 16:03 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: timcaffrey420

On Wednesday, July 1, 2020 at 11:14:04 AM UTC-4, Scott Lurndal wrote:
> timcaffrey420@gmail.com writes:
>> On Monday, June 29, 2020 at 8:08:47 PM UTC-4, Scott Lurndal wrote:
>>> Douglas Miller <durgadas311@gmail.com> writes:
>>>> On Monday, June 29, 2020 at 3:40:49 PM UTC-5, anti...@math.uni.wroc.pl w=
>> rot=3D
>>>> e:
>>>> > I wonder how much security was provided on early IBM mainframes.
>
>>> =20
>>> The Burroughs mainframe MCP (Master Control Program) from the mid 1960's
>>> provided the concept of named files in directories on various spinning me=
>> dia
>>> including magnetic tape, drum, HPT disk and later removable packs.
>>> =20
>>> It also provided a usercode based security system with 9 heirarchical
>>> privilege levels controlling access to various MCP capabilities and
>>> access control to both devices such as card readers as well as individual
>>> files on disk or pack. Aside from the standard user and other permissio=
>> ns
>>> (read/write) there was the concept of a guard file associated with a disk
>>> file that contained fine-grained permissions (e.g. granting a particular
>>> set of users access to the file by usercode).
>>> =20
>>> Thus most card decks started with a LI (Login) card:
>>> =20
>>> ?LI 9895 FRED 33561
>>> =20
>>> Where the usercode was 9895 (qn in EBCDIC), the password FRED and the
>>> charge code for job accounting/chargeback was 33561.
>>> =20
>>> Way ahead of the (much larger) competition.
>>> =20
>>> And the infamous 'BO' (Black Out) MCP command that would overwrite 10
>>> M, W and O characters on the operator console to provide a blacked out
>>> space for entering the password. Later, on video terminals, only the
>>> final sequence of 'M' characters was printed. Since the MCP ignored
>>> any input character after the 'BO', one could enter on a video console
>>> the command "BOOBS" and recieve the reply "MMMMMMMMM".
>>
>> The CP3680 terminal front end (which mostly ran on Burroughs Medium systems=
>> ,
>> but you could hook it up to an HP3000 as well) had pretty sophisticated sec=
>> urity.
>
> The CP3680 was an HP-2000 under the skins, and was originally developed
> by a customer; they used a magtape channel to connect it to the medium systems host.
>

It was a highly customized (as in, custom instructions) HP21MX, and was developed by Systems Research, Inc (in Michigan), which Burroughs bought in the early 80s. The magtape interface was easiest to connect to, and even Unisys used an emulated tape channel to talk to the CP2000s many years later.

One of these days I need to ship the manuals to bitsavers....

- Tim
Re: Early mainframe security [message #396373 is a reply to message #396367] Wed, 01 July 2020 20:52 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
timcaffrey420@gmail.com writes:
> On Wednesday, July 1, 2020 at 11:14:04 AM UTC-4, Scott Lurndal wrote:
>> timcaffrey420@gmail.com writes:

>>> The CP3680 terminal front end (which mostly ran on Burroughs Medium syst=
> ems=3D
>>> ,
>>> but you could hook it up to an HP3000 as well) had pretty sophisticated =
> sec=3D
>>> urity.
>> =20
>> The CP3680 was an HP-2000 under the skins, and was originally developed
>> by a customer; they used a magtape channel to connect it to the medium =
> systems host.
>> =20
>
> It was a highly customized (as in, custom instructions) HP21MX, and was dev=
> eloped by Systems Research, Inc (in Michigan), which Burroughs bought in th=
> e early 80s. The magtape interface was easiest to connect to, and even Uni=
> sys used an emulated tape channel to talk to the CP2000s many years later.
>
> One of these days I need to ship the manuals to bitsavers....

Please do. My V-series simulator currently only emulates the B974 and
the Telcom DLP for datacommm connectivity (I wrote the B874/B974 DCP code
in MCPVS 2.0 that interfaced the hardware to the MCS (e.g. the code loaded
when you 'SO DCP')).

Do you have the source for SWITCH by any chance, since the CP3680 bypassed
the MCP DCP code and talked directly (pun intended) to SWITCH, my current
DCP support in the simulator won't be of much use.

The B874 attached using a modified host transfer (Disk/Pack) DLP.
Re: Early mainframe security [message #396376 is a reply to message #396345] Wed, 01 July 2020 23:21 Go to previous messageGo to previous message
Jon Elson is currently offline  Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
Senior Member
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
Pages (2): [1  2    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: [OT] Series of Three Videos on an Unusual Slide Rule
Next Topic: QuantumLink survives!
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 13:23:38 EDT 2024

Total time taken to generate the page: 0.36487 seconds