Discussion:
Early mainframe security
Add Reply
a***@math.uni.wroc.pl
2020-06-29 20:40:48 UTC
Reply
Permalink
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
Peter Flass
2020-06-29 20:49:59 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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
Dan Espen
2020-06-29 20:53:30 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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
a***@math.uni.wroc.pl
2020-06-29 23:59:42 UTC
Reply
Permalink
Post by Dan Espen
Post by a***@math.uni.wroc.pl
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
Peter Flass
2020-06-30 00:24:48 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
Post by Dan Espen
Post by a***@math.uni.wroc.pl
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
Thomas Koenig
2020-06-30 07:57:14 UTC
Reply
Permalink
Post by Peter Flass
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...
Kerr-Mudd,John
2020-06-30 08:21:31 UTC
Reply
Permalink
[]
Post by Peter Flass
Post by a***@math.uni.wroc.pl
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.
Douglas Miller
2020-06-29 20:55:25 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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.
J. Clarke
2020-06-29 21:40:48 UTC
Reply
Permalink
On Mon, 29 Jun 2020 13:55:25 -0700 (PDT), Douglas Miller
Post by Douglas Miller
Post by a***@math.uni.wroc.pl
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.
Scott Lurndal
2020-06-30 00:08:45 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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".
t***@gmail.com
2020-07-01 14:38:34 UTC
Reply
Permalink
Post by Scott Lurndal
Post by a***@math.uni.wroc.pl
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).
?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
Scott Lurndal
2020-07-01 15:14:02 UTC
Reply
Permalink
rot=3D
Post by Scott Lurndal
Post by a***@math.uni.wroc.pl
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
Post by Scott Lurndal
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
Post by Scott Lurndal
(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
=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.
t***@gmail.com
2020-07-01 20:03:06 UTC
Reply
Permalink
Post by Scott Lurndal
rot=3D
Post by Scott Lurndal
Post by a***@math.uni.wroc.pl
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
Post by Scott Lurndal
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
Post by Scott Lurndal
(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
=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
Scott Lurndal
2020-07-02 00:52:48 UTC
Reply
Permalink
Post by Scott Lurndal
The CP3680 terminal front end (which mostly ran on Burroughs Medium syst=
ems=3D
Post by Scott Lurndal
,
but you could hook it up to an HP3000 as well) had pretty sophisticated =
sec=3D
Post by Scott Lurndal
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.
Post by Scott Lurndal
=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.
t***@gmail.com
2020-07-12 01:04:01 UTC
Reply
Permalink
Post by Scott Lurndal
Post by Scott Lurndal
The CP3680 terminal front end (which mostly ran on Burroughs Medium syst=
ems=3D
Post by Scott Lurndal
,
but you could hook it up to an HP3000 as well) had pretty sophisticated =
sec=3D
Post by Scott Lurndal
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.
Post by Scott Lurndal
=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.
I have micro-fiche for everything, but I'm not sure it is actually legal
for me to make it public.

I might remember enough to answer some high level questions about how Switch
worked, although I did very little work on it. I mostly worked on the CP3680 code (which I got to know really well, but that was some time ago).

- Tim
Grant Taylor
2020-07-12 01:10:11 UTC
Reply
Permalink
Post by t***@gmail.com
I have micro-fiche for everything, but I'm not sure it is actually
legal for me to make it public.
If / when you decide to part with the micro-fiche, you might reach out
to Internet Archive and / or Bitsavers as one or both of them has
content saved, so that it doesn't end up lost, that is not public for
that reason. But the information is safe.
--
Grant. . . .
unix || die
John Levine
2020-07-12 02:50:43 UTC
Reply
Permalink
Post by t***@gmail.com
Post by Scott Lurndal
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.
I have micro-fiche for everything, but I'm not sure it is actually legal
for me to make it public.
How old is it? Before 1964, computer programs weren't copyrighted.
--
Regards,
John Levine, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
t***@gmail.com
2020-07-13 21:26:09 UTC
Reply
Permalink
Post by John Levine
Post by t***@gmail.com
Post by Scott Lurndal
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.
I have micro-fiche for everything, but I'm not sure it is actually legal
for me to make it public.
How old is it? Before 1964, computer programs weren't copyrighted.
--
Regards,
Please consider the environment before reading this e-mail. https://jl.ly
80s, and it has copyright notices in it (IIRC).

- Tim
David Wade
2020-06-29 22:00:17 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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
a***@math.uni.wroc.pl
2020-06-30 00:27:35 UTC
Reply
Permalink
Post by David Wade
Post by a***@math.uni.wroc.pl
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.
Post by David Wade
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
John Levine
2020-06-30 02:58:15 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
David Wade
2020-06-30 10:34:06 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
Post by David Wade
Post by a***@math.uni.wroc.pl
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
Post by a***@math.uni.wroc.pl
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.
Post by a***@math.uni.wroc.pl
Post by David Wade
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
Peter Flass
2020-06-30 13:15:12 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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.
Post by a***@math.uni.wroc.pl
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
a***@math.uni.wroc.pl
2020-06-30 14:01:32 UTC
Reply
Permalink
Post by Peter Flass
Post by a***@math.uni.wroc.pl
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.
Post by a***@math.uni.wroc.pl
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
David Wade
2020-06-30 21:39:11 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
Post by Peter Flass
Post by a***@math.uni.wroc.pl
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.
Post by a***@math.uni.wroc.pl
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
Jon Elson
2020-07-01 00:37:57 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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
John Levine
2020-06-29 22:18:46 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Peter Flass
2020-06-29 22:49:29 UTC
Reply
Permalink
Post by John Levine
Post by a***@math.uni.wroc.pl
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
Grant Taylor
2020-06-30 00:28:27 UTC
Reply
Permalink
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
Quadibloc
2020-06-30 04:11:50 UTC
Reply
Permalink
Post by Grant Taylor
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
David Wade
2020-06-30 10:35:22 UTC
Reply
Permalink
Post by Grant Taylor
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
Charlie Gibbs
2020-06-30 22:18:42 UTC
Reply
Permalink
Post by David Wade
Post by Grant Taylor
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.
\ / <***@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.
Scott Lurndal
2020-07-01 15:08:56 UTC
Reply
Permalink
Post by Charlie Gibbs
Post by David Wade
Post by Grant Taylor
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.
Thomas Koenig
2020-06-30 07:51:28 UTC
Reply
Permalink
[x-post, followup back to a.f.c.]
Post by John Levine
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? :-)
Bob Eager
2020-06-30 08:49:10 UTC
Reply
Permalink
Post by Thomas Koenig
[x-post, followup back to a.f.c.]
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
Ahem A Rivet's Shot
2020-06-30 08:43:01 UTC
Reply
Permalink
On Mon, 29 Jun 2020 20:40:48 +0000 (UTC)
Post by a***@math.uni.wroc.pl
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/
Jon Elson
2020-07-01 00:23:36 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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
Peter Flass
2020-07-01 01:03:54 UTC
Reply
Permalink
Post by Jon Elson
Post by a***@math.uni.wroc.pl
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.
Post by Jon Elson
Jon
--
Pete
J. Clarke
2020-07-01 02:32:12 UTC
Reply
Permalink
On Tue, 30 Jun 2020 18:03:54 -0700, Peter Flass
Post by Peter Flass
Post by Jon Elson
Post by a***@math.uni.wroc.pl
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.
John Levine
2020-07-01 03:21:13 UTC
Reply
Permalink
Post by J. Clarke
Post by Peter Flass
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, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
J. Clarke
2020-07-01 03:52:23 UTC
Reply
Permalink
Post by John Levine
Post by J. Clarke
Post by Peter Flass
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.
Dan Espen
2020-07-01 03:56:40 UTC
Reply
Permalink
Post by John Levine
Post by J. Clarke
Post by Peter Flass
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
Jon Elson
2020-07-02 03:21:32 UTC
Reply
Permalink
Post by Peter Flass
Post by Jon Elson
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
t***@gmail.com
2020-07-01 14:33:05 UTC
Reply
Permalink
Post by a***@math.uni.wroc.pl
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
Anne & Lynn Wheeler
2020-08-03 22:25:56 UTC
Reply
Permalink
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
Anne & Lynn Wheeler
2020-08-03 22:58:03 UTC
Reply
Permalink
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
Loading...