Post by firstname.lastname@example.org
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?
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".