TSS/360

Anne & Lynn Wheeler

unread,

Nov 25, 2001, 12:31:37 PM11/25/01

to

ehs suggested a repost here ... possibly comparing the size of the
Multics & TSS/360 organizations.

IBM had bid 360/67 for multics (maybe still 360/62 at that time before
models 60, 62, 70, got renamed 65, 67, & 75 because of the faster
memory technology) and cambridge (2nd & 4th floor, 545 tech. sq) had
planned to play a significant part in that activity.

Loosing the bid, IBM created a group in mohansic for TSS/360, a
virtual memory operating system that would run on the 360/67. This
would have been sometime '66. I think by '68, the mohansic
organization was up to somewhere in the 1000-1200 headcount range
working on TSS/360. This continued up through the '70s although TSS
was "decommitted" (it wasn't actually canceled, but the group was
reduced to possibly 20-30 head-count responsible for supporting the
dozen or so major customers).

Later in the '70s & early '80s, TSS(/370) saw some significant
re-vitalization from AT&T and bell-labs .... using it as sort-of a
microkernel for Unix running on mainframes.

During this period, the cambridge group at the 4th floor started the
virtual machine project; first with CP/40 and CMS i.e., custom,
relocation hardware was added to a 360/40 and the virtual machine
monitor was developed while the user environment "CMS" was being
developed in parallel to "run" in a virtual machine. Finally a 360/67
became available in Cambridge and the CP/40 monitor was ported to
360/67 (changing its name to CP/67). I would estimate that by '70 or
'71 3-4 times as many 360/67s were running CP/67 as was running
TSS/360.

The CP/67 group was split off from the scientific center, eventually
taking over the 3rd floor and absorbing most of the IBM Boston
Programming Center (and many of the people that had worked on CPS
... a non-virtual-memory, 360-based "conversational programming
system" as well as jean sammet and some misc. other people). The
group/product was renamed VM/370 for the port/introduction of virtual
memory on the 370 line of computers.

Eventually, the group was bursting at the seams in 545 tech. sq and
was relocated to a recently vacated SBS building in burlington mall
(SBS been turned over/sold to CDC as part of gov. settlement of ibm
getting out of service bureau business).

Later in the '70s, when the burlington mall group was shutdown (the
group had grown to possible 200 or so by that time) and all the people
were told to move to POK to work on the VMTOOL ... a significant
number left IBM (especially a lot of the CMS developers) and went to
work for DEC on VMS (this was one of those periods when there wasn't
going to be anymore VM/370 releases and all the people were needed to
support the "internal-only" VMTOOL ... a virtual machine monitor tool
that was dedicaetd to MVS/XA development).

a lot of this is covered in much more detail (including misc & sundry CTSS
happenings) in Melinda's history paper at:
http://pucc.princeton.edu/~melinda/

--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/

Tom Van Vleck

unread,

Nov 26, 2001, 9:18:21 AM11/26/01

to

Lynn's post sure brings back memories of the 60s.
I moved from Project MAC to the MIT Comp Center
about 1969, continuing to work on Multics but also
taking on responsibility for the declining CTSS and
the 360/67 that the MIT Urban Systems Lab had obtained,
run for a year, and then turned over to the Center.
So I got to meet and work with some of the CP/CMS
developers on the third floor of Tech Square, and
heard presentations about TSS/360 at IBM SHARE meetings.

More pointers:
CTSS http://www.multicians.org/thvv/7094.html
CP/CMS http://www.multicians.org/thvv/360-67.html

Douglas H. Quebbeman

unread,

Nov 26, 2001, 10:53:07 AM11/26/01

to

"Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
news:u7kserc4...@earthlink.net...

>
> ehs suggested a repost here ... possibly comparing the size of the
> Multics & TSS/360 organizations.

It's an OT remark for this newgroup, but it sure would be nice
if a copy of TSS/360 or CP/67 would surface for use with the
Hercules emulator...

-dq

Anne & Lynn Wheeler

unread,

Nov 26, 2001, 12:31:39 PM11/26/01

to

Tom Van Vleck <th...@multicians.org> writes:

> Lynn's post sure brings back memories of the 60s.
> I moved from Project MAC to the MIT Comp Center
> about 1969, continuing to work on Multics but also
> taking on responsibility for the declining CTSS and
> the 360/67 that the MIT Urban Systems Lab had obtained,
> run for a year, and then turned over to the Center.
> So I got to meet and work with some of the CP/CMS
> developers on the third floor of Tech Square, and
> heard presentations about TSS/360 at IBM SHARE meetings.

in terms of group size ... the TSS/360 group had grown to about
1000-1200 in the late '60s ... while the CP/40,CP/67,CMS group (within
the science center at 545 tech sq) had grown to 14 by the start of
1970 (CSC on about 1/2 the 4th floor, around 35 people total, with the
machine room on about 1/2 of the 2nd floor).

The CP/67 group grew quickly during 70/71 from 14 to maybe 60(?)
taking over 3/4ths of the 3rd floor, absorbing the boston programming
center, etc (and changed its name to vm/370 officially when virtual
memory was finally announced for 370 machines).

As it was bursting at the seams on the 3rd floor, the group moved out
to the vacated (ibm) service bureau building in burlington mall where
the group grew to 200 or so people until '76 when it was shutdown and
moved to POK.

The VM/370 group at its peak in the '70s with thousands of
installations was possibly 1/6th the size of the tss/360 group at its
peak (with its dozen installations).

Jeff Raben

unread,

Nov 28, 2001, 12:45:54 PM11/28/01

to

how come there is nothing here about LLMPS (lincoln labs)
and MTS (Michigan Timeshare System) that originally ran on the /67?

The combination ran on many univerity machines.

Jeff
and stir with a Runcible spoon...

Stephen H. Westin

unread,

Nov 28, 2001, 1:59:47 PM11/28/01

to

jra...@cascinc.com (Jeff Raben) writes:

> how come there is nothing here about LLMPS (lincoln labs)
> and MTS (Michigan Timeshare System) that originally ran on the /67?
>
> The combination ran on many univerity machines.

I think you mean UMMPS (the University of Michigan Multiprogramming
System), the substrate for MTS. UMMPS may have been originally based
on something from Lincoln Labs.

I think the total count of installations never grew beyond about ten.

But anyway, it's an interesting part of the whole story. As I
understand it (based on tales and talks from the Michigan side of
things), it all starts with IBM's unsuccessful bid on the Multics
hardware. This was deemed, in retrospect, a Bad Thing, and IBM became
rather more cooperative with universities, including Michigan. The
specified machine was known as the 360/65M ("M" for "Michigan"), and
seen as a one-off device to save prestige.

But the IBM view of the market changed (or at least politics within
IBM changed), and it soon became the 360/67, a full-fledged production
model, and TSS/360 was to be written to run on it to provide full
virtual-memory time sharing. As Lynn Wheeler has described, a large
team was put together. What wasn't mentioned was how late it all
was. Michigan got a 360/50, I believe, as a stopgap, and MTS was
originally written as a toy time-sharing system for that. The '67
arrived in, aptly enough, 1967, but with no OS. The staff grew tired
of running in Model 65 mode, and enhanced MTS to use the VM hardware
on the '67. This was all a 2-person effort, or near it.

They stole various compilers and utilities from OS/360 and hacked them
to run on MTS, put together a simple file system, etc. By the time
TSS/360 arrived, it was deemed to be not worth the bother, and MTS
continued as the OS for academic computing at Michigan. It ran on the
360/67 and was modified for symmetric multiprocessing when that
machine was upgraded with a second processor. Later it was ported to a
370/168 as an interim measure, then the first Amdahl 470/V6. It
continued on various big IBM (and compatible) hardware until about
1995.

Other universities running MTS included Wayne State (in Detroit), the
University of British Columbia, and the University of Grenoble, if
memory serves.

The executive summary would be that it was a much less ambitious
project than Multics (or TSS/360), and probably succeeded because of
that. For example, it lacked a tree directory structure, E-mail, and
shared files for several years; they were added later. But then, they
had a system in production in May, 1967. Another element of its
success was shared with Multics, CP/67, and Unix: the developers were
actually running an installation with real users.

The relationship with IBM didn't remain that close; while Michigan
specified quite a bit of what became the 360/67, the 370's ignored
certain suggestions from that quarter.

For more details, see
<http://www.itd.umich.edu/~doc/Digest/0596/feat02.html>.

--
-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.

Anne & Lynn Wheeler

unread,

Nov 28, 2001, 4:16:18 PM11/28/01

to

jra...@cascinc.com (Jeff Raben) writes:

note that LLMPS was mostly simple (ibm/360) multitasker with a number
of simple unit-record and tape utilities (card->tape, print tape, copy
tape, punch cards, etc). It was a contributed Share program ... I
still have the LLMPS manual in a box someplace.

The (strong) rumor is that MTS started off using the LLMPS multitasker
for the original base for developing MTS ... Michigan Terminal System,
an interactive, virtual memory system for the 360/67 ... offering a
lot of vanilla os/360 facilities in a interactive, online environment.

Lincolm Labs had a duplex '67 and was the first installation to get
CP/67 installed from the Cambridge Science Center (sometime in
'67). The university that I was at was the 2nd installation (after
lincoln) ... getting CP/67 installed the last week in Jan. 1968.

For the 360/67 there were (at least) virtual memory, paging systems
TSS/360
CP/67
MTS

There was also a virtual memory, non-paging hack done to OS/360 MVT13
running on a pair of 360/67s at Boeing Huntsville. OS/360 for long
running applications could get into severe storage
fragmentation. Boeing Huntsville ran a number of long-running 2250
(large vector display, used for CAD design and other) applications
that would eventually result in severe OS/360 storage
fragmentation. The virtual memory, non-paging hack to MVT13 was to
help medicate storage fragmentation problems (i.e. use virtual memory
to be able to provide something that looked like contiguous storage
regions for each application).

There was also a special tri-plex, fully redundant 360/67 for some
real-time gov. project being done by Lockheed ... which was writing
their own special code (I don't know much about this one).

In the '60s, there were also at least two service bureau spin-offs
using CP/67, one was NCSS in stamford, conn. and the other was IDC (a
number of lincoln labs. people) out in waltham.

In the middle of June, '68 Cambridge Science Center was holding a one
week CP/67 class for prospective & current customers) at a location in
Beverly Hills that the University sent me to. The week (possibly
friday) the class was to start, several of the people resigned from
CSC as part of forming the NCSS startup. As a result, I got pressed
into teaching a lot of the class. I believe that sometime in the '70s,
NCSS may have also installed a Multics system.

Dec. '68 or Jan. '69, Boeing created Boeing Computer Services with the
idea of moving all of their commerical dataprocessing into BCS and be
able to start operating it as a profit center (as opposed to cost
center). During '69, spring break, IBM talked me into giving a one
week computer class to the BCS technical staff (that had been
integrated into BCS up to that point). About that time they moved the
Boeing Huntsville 360/67s to Seattle. Boeing eventually had quite a
few 360/67s running CP/67.

misc. MTS & LLMPS postings from the past:
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#174 S/360 history

http://www.garlic.com/~lynn/2000.html#89 Ux's good points.

http://www.garlic.com/~lynn/2000.html#91 Ux's good points.

http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)

http://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000f.html#52 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs)

http://www.garlic.com/~lynn/2000g.html#2 TSS ancient history, was X86 ultimate CISC? designs)

http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001h.html#24 "Hollerith" card code to EBCDIC conversion
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?

http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?

http://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question

misc. bcs postings
http://www.garlic.com/~lynn/99.html#32 Roads as Runways Was: Re: BA Solve
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001b.html#8 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
http://www.garlic.com/~lynn/2001b.html#9 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001g.html#56 YKYBHTLW....
http://www.garlic.com/~lynn/2001l.html#32 mainframe question

Stephen H. Westin

unread,

Nov 28, 2001, 4:27:51 PM11/28/01

to

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> jra...@cascinc.com (Jeff Raben) writes:
>
> > how come there is nothing here about LLMPS (lincoln labs)
> > and MTS (Michigan Timeshare System) that originally ran on the /67?
> >
> > The combination ran on many univerity machines.
> >
> > Jeff
> > and stir with a Runcible spoon...
>
> note that LLMPS was mostly simple (ibm/360) multitasker with a number
> of simple unit-record and tape utilities (card->tape, print tape, copy
> tape, punch cards, etc). It was a contributed Share program ... I
> still have the LLMPS manual in a box someplace.
>
> The (strong) rumor is that MTS started off using the LLMPS multitasker
> for the original base for developing MTS ... Michigan Terminal System,
> an interactive, virtual memory system for the 360/67 ... offering a
> lot of vanilla os/360 facilities in a interactive, online environment.

That's really selling MTS short. Its user interface resembled OS not
at all, file structures were totally different, there was no linker,
etc.

What did happen was that various useful OS packages were ported: the
level G and H FORTRAN compilers and APL\360, to my knowledge. I
suppose many of the 3rd-party programs such as the Waterloo
WATFOR/WATFIV FORTRAN environment, PL/C, and Algol W were ported from
OS as well. This only made sense, as the development team was always
tiny by IBM standards.

But editors (including the full-screen CRT editor) and
many other things were home-grown for MTS. I especially remember
Interactive Fortran, a source-level interactive development
environment circa 1975.

Actually, I rather liked the MTS file system. There were two basic
kinds of files: sequential and line-number files. The latter were the
norm, and allowed you to access each line randomly and alter it at
will. Because of this, the editor had no notion of loading or saving
files; you just made alterations directly to the disk image, with a
maximum of a single line at risk.

<snip>

Tom Van Vleck

unread,

Nov 28, 2001, 5:59:34 PM11/28/01

to

Lynn Wheeler wrote:

> I believe that sometime in the '70s,
> NCSS may have also installed a Multics system.

I don't believe this happened.
I think there was a sales effort but no sale was made,
alas. Some good folks were at NCSS.

Tom Van Vleck

unread,

Nov 28, 2001, 6:03:36 PM11/28/01

to

Jeff Raben wrote:

> how come there is nothing here about LLMPS (lincoln labs)
> and MTS (Michigan Timeshare System) that originally ran on the /67?

There is a little about MTS on my 360/67 page
http://www.multicians.org/thvv/360-67.html
and a link on the Multics links page to Susan Topol's article:
http://www.itd.umich.edu/~doc/Digest/0596/feat02.html

Edward Rice

unread,

Nov 29, 2001, 2:16:40 AM11/29/01

to

In article <uy9kq1...@earthlink.net>,

Anne & Lynn Wheeler <ly...@garlic.com> wrote:

> CSC as part of forming the NCSS startup. As a result, I got pressed
> into teaching a lot of the class. I believe that sometime in the '70s,
> NCSS may have also installed a Multics system.

I'm pretty sure that National CSS never bought Multics, but I know we
marketed to them. Your summary also explains a few odd things I'd never
understood, like why Wayne State became a Multics site. (Wayne State?
where'd THEY come from?)

Edward

Stephen H. Westin

unread,

Nov 29, 2001, 9:01:48 AM11/29/01

to

ehr...@his.com (Edward Rice) writes:

Wayne State is a large university in inner-city Detroit, comparable in
size to Michigan State and the University of Michigan, but lacking
their visibility and prestige.

Funny, they were an MTS site. And they're not listed on the Multicians
Web site. Was there a typo above?

Edward Rice

unread,

Nov 29, 2001, 1:38:58 PM11/29/01

to

In article <uy9kp7...@graphics.cornell.edu>,

westin*nos...@graphics.cornell.edu (Stephen H. Westin) wrote:

> ehr...@his.com (Edward Rice) writes:
>
> > In article <uy9kq1...@earthlink.net>,
> > Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> >
> > > CSC as part of forming the NCSS startup. As a result, I got pressed
> > > into teaching a lot of the class. I believe that sometime in the
'70s,
> > > NCSS may have also installed a Multics system.
> >
> > I'm pretty sure that National CSS never bought Multics, but I know we
> > marketed to them. Your summary also explains a few odd things I'd
never
> > understood, like why Wayne State became a Multics site. (Wayne State?

> > where'd THEY come from?)
>
> Wayne State is a large university in inner-city Detroit, comparable in
> size to Michigan State and the University of Michigan, but lacking
> their visibility and prestige.
>
> Funny, they were an MTS site. And they're not listed on the Multicians
> Web site. Was there a typo above?

I /thought/ Wayne State was a site. At the time, after my first thought
(above), all I could come up with as a rationale was that they were a
vo-tech'y school near enough to Detroit to want a Multics system just like
the car companies had. I'm fairly sure I've seen written indications of
them being a site, but I definitely have none in my possession -- FSO could
wander kind of all over the map when it came to Multics, but the Major
Accounts Office for Automotive was /strictly/ hands-off and
keep-your-distance. I'm not clear on why -- we swapped technical
information with most of the sites, but almost none at all with the Detroit
shops. And GM was the /only/ other site in the Multics world running
production with multi-level security enabled. (CISL did, I know, but that
was development.)

Edward

Vincent Scarafino

unread,

Nov 29, 2001, 2:29:37 PM11/29/01

to

Oakland University was a Multics site. It's located just north of
Detroit. Could it be Oakland you are thinking about? Wayne had MTS.

Edward Rice wrote:

...

Edward Rice

unread,

Nov 30, 2001, 2:06:50 AM11/30/01

to

In article <3C068CA1...@ford.com>,
Vincent Scarafino <vsca...@ford.com> wrote:

> Oakland University was a Multics site. It's located just north of
> Detroit. Could it be Oakland you are thinking about? Wayne had MTS.

<g> Could certainly be. I'm beginning to get the idea that WSU had MTS
rather than Multics.

On a digressive note, Steve Lipner was on the tube this evening, some PBS
show about hackery that I wasn't able to catch the start or the end of. He
mentioned that he had, at a previous job, run a project to develop an A-1
secure computing system, and that at the end of the project he'd made the
decision to shut the whole thing off, there being no market for the
product. Sound familiar to anybody?

Steve's at Microsoft now, and expressed "real sorrow" that all Windows
users hadn't known to update their software from the Microsoft web-site to
prevent hacker mischief from happening to them. Ahem.

-- Edward

Douglas H. Quebbeman

unread,

Nov 30, 2001, 7:56:35 AM11/30/01

to

"Edward Rice" <ehr...@his.com> wrote in message
news:B82C9A3A...@max1h-119.his.com...

> In article <3C068CA1...@ford.com>,
> Vincent Scarafino <vsca...@ford.com> wrote:
>
> > Oakland University was a Multics site. It's located just north of
> > Detroit. Could it be Oakland you are thinking about? Wayne had MTS.
>
> <g> Could certainly be. I'm beginning to get the idea that WSU had MTS
> rather than Multics.
>
> On a digressive note, Steve Lipner was on the tube this evening, some PBS
> show about hackery that I wasn't able to catch the start or the end of.
He
> mentioned that he had, at a previous job, run a project to develop an A-1
> secure computing system, and that at the end of the project he'd made the
> decision to shut the whole thing off, there being no market for the
> product. Sound familiar to anybody?

I saw that, and it red-flagged in my mind only because I'd thought
I'd read here in this newsgroup once in the past that A1 level had
never been achieved...

> Steve's at Microsoft now, and expressed "real sorrow" that all Windows
> users hadn't known to update their software from the Microsoft web-site to
> prevent hacker mischief from happening to them. Ahem.

The MS solution seems to be to have Windows check for updates
automatically every day. When they figure out how to do this in a
*transparent* fashion, it may become a Useful Idea. Right now,
it's the first thing users ask me to disable...

-dq

Tom Van Vleck

unread,

Nov 30, 2001, 11:17:20 AM11/30/01

to

Edward Rice wrote:

> On a digressive note, Steve Lipner was on the tube this evening, some PBS
> show about hackery that I wasn't able to catch the start or the end of. He
> mentioned that he had, at a previous job, run a project to develop an A-1
> secure computing system, and that at the end of the project he'd made the
> decision to shut the whole thing off, there being no market for the
> product. Sound familiar to anybody?

That would be Digital Secure VMS. Several Multicians worked
on this system. Douglas Quebbeman asks if Orange Book level
A1 was ever achieved: secure VMS was designed to pass A1 but
didn't complete evaluation. As I remember, Steve said that

development took so long that people wanted workstations instead

of time-sharing systems by the time it was ready.

Alan T. Bowler

unread,

Nov 30, 2001, 12:05:27 PM11/30/01

to

"Douglas H. Quebbeman" wrote:
>
> I saw that, and it red-flagged in my mind only because I'd thought
> I'd read here in this newsgroup once in the past that A1 level had
> never been achieved...

I thought the Honeywel SCOMP system achieved A1.

kar...@watson.ibm.com

unread,

Nov 30, 2001, 1:13:14 PM11/30/01

to

In article <B82C9A3A...@max1h-119.his.com>,

ehr...@his.com (Edward Rice) writes:
>
>On a digressive note, Steve Lipner was on the tube this evening, some PBS
>show about hackery that I wasn't able to catch the start or the end of. He
>mentioned that he had, at a previous job, run a project to develop an A-1
>secure computing system, and that at the end of the project he'd made the
>decision to shut the whole thing off, there being no market for the
>product. Sound familiar to anybody?
>
>Steve's at Microsoft now, and expressed "real sorrow" that all Windows
>users hadn't known to update their software from the Microsoft web-site to
>prevent hacker mischief from happening to them. Ahem.
>
> -- Edward

For an alternate view of what happened to that A1 system and whether there
was or was not a market, you should read this paper. (Of course, I'm biased
about it.)

Karger, P.A., M.E. Zurko, D.W. Bonin, A.H. Mason, and C.E. Kahn,
A Retrospective on the VAX VMM Security Kernel. IEEE Transactions
on Software Engineering, 1991. 17(11): p. 1147-1165.

The problems had much more to do with the needed microcode changes not being
made to the latest VAX processors, with delays in getting full networking
support implemented, and with US government export controls
on A1 operating systems.

The external field test customers (both in the US and properly export
licensed NATO partners) were actually
quite pleased with the system, and the cost and performance were quite
acceptable. Not being able to sell the system to over 50% of the customers,
due to export controls was a bigger problem. How do you explain to a customer
that we have a MUCH more secure system, but you aren't allowed to buy it?
That customer is likely to go away angry and buy from the competition instead,
regardless of whether the competition is secure or not.

A number of ex-Multicians worked on that system, and the design was based
heavily on Phil Jansen's and Dave Reed's theses at MIT/LCS. It was a virtual
machine monitor, much in the spirit of CP/67 or VM/370.

It was the first system to meet all three goals of high security, good
performance, AND compatibility with existing operating systems (VMS and UNIX).
All previous high security systems had only met two out of three of those goals.

I often wonder where we would be today in computer security, if either Multics
or the VAX VMM system had been properly marketed and supported. Just being
technically successful is NOT even close to sufficient to be successful
in the marketplace.

cbbr...@acm.org

unread,

Nov 30, 2001, 1:28:14 PM11/30/01

to

"Alan T. Bowler" <atbo...@thinkage.ca> writes:
> "Douglas H. Quebbeman" wrote:
> > I saw that, and it red-flagged in my mind only because I'd thought
> > I'd read here in this newsgroup once in the past that A1 level had
> > never been achieved...

> I thought the Honeywell SCOMP system achieved A1.

Boeing's "MLS LAN Secure Network Server System" was rated A1 in '91,
as well as their "MLS LAN Network Component MDIA," in 1994.

Gemini Computers' "Gemini Trusted Network Processor" was rated A1 in
'94.

Wang Federal, Inc. SCOMP Version STOP Release 2.1 was rated A1 in '84

Only SCOMP _might_ have been an operating system, per se; MLS LAN and
the Gemini system were both rated A1 as "Network Components." There's
some rumor that a Wang Government Services "XTS-200" might have been
rated A1 as an OS, but more recent history involves XTS-200 and
XTS-300 being B3-rated...
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/security.html
Rules of the Evil Overlord #79. "If my doomsday device happens to come
with a reverse switch, as soon as it has been employed it will be
melted down and made into limited-edition commemorative coins."
<http://www.eviloverlord.com/>

Edward Rice

unread,

Nov 30, 2001, 9:22:02 PM11/30/01

to

In article <3c078...@news.iglou.com>,

"Douglas H. Quebbeman" <do...@ixnayamspayiglou.com> wrote:

> I saw that, and it red-flagged in my mind only because I'd thought
> I'd read here in this newsgroup once in the past that A1 level had
> never been achieved...

... by a general-purpose system. Or a mainframe system. The other systems
that made A-1 were small systems. The Honeywell one was the SCOMP, a
dedicated communications processor.

With today's tools, and horsepower, it seems to me that we /ought/ to have
facilities around that are provably secure and reliable, rather than what
we do have.

> The MS solution seems to be to have Windows check for updates
> automatically every day. When they figure out how to do this in a
> *transparent* fashion, it may become a Useful Idea. Right now,
> it's the first thing users ask me to disable...

And, the updates don't necessaryily fix what's wrong. Nothing to stop an
update from introducing new bugs. ehr

cbbr...@acm.org

unread,

Nov 30, 2001, 9:59:51 PM11/30/01

to

kar...@watson.ibm.com () writes:
> I often wonder where we would be today in computer security, if
> either Multics or the VAX VMM system had been properly marketed and
> supported. Just being technically successful is NOT even close to
> sufficient to be successful in the marketplace.

I wonder what features could get introduced that would involve
learning from some of the lessons from Multics.

The two competing security "mentalities" at present seem to be:

a) Strewing ACL bits across filesystems, which creates the
management nightmare that you have to do vast quantities of
"pointy-clicky stuff" to get things done.

And then, since "point-and-click" means that any idiot can be a
system administrator, and probably usually is, there is likely
not to be a coherent set of _policy_ to surround what the "bits"
ought to look like.

<http://www.usenix.org/publications/login/1998-6/acls.html>
discusses this, and promotes the use of the authors' "cfengine"
tool to describe ACL policies.

Virtually all ACL systems involve attaching some sort of metadata
to files, which means that fixing up ACLs involves "touching"
whole hordes of files.

I am aware of one counterexample; TOPS-10 had a file sharing
scheme where a daemon called FILDAE would, if an attempt to
[somehow manipulate - read/write/delete] a file failed, look at
an ACL "policy file" to see if the ACL info would grant the
access that file permissions failed to grant. I preserved a
discussion about this at <http://www.cbbrowne.com/info/fs.html>,
which was wise, in retrospect, as Deja.com is no more.

b) Capabilities.

Capabilities are cool, because you attach them to programs, thus
granting, to the program, the ability to access only what you set
up the capabilities to grant access to.

One company (Brickhouse?) set up a Linux system where you were
granted root access, and given the challenge to try to access a
certain file. They set up capabilities to deny Just About
Everything to root, with the peculiar result that people could
log in "as root," and have just about no rights to do anything at
all. Cool. Not necessarily practical, though.

The problem is that you wind up having to define and set
_site-dependent_ policy for hordes and hordes of capabilities.
It's just as bad as ACLs, only worse, because at least there's
enough history of working with ACLs that there are _some_ tools
to manage the things, and _some_ understanding of what policies
might look like.

What seems more likely to happen, over time, is for more and more Unix
services that traditionally ran as root to get their own
severely-restricted user IDs. Sendmail used to be a giant security
rash; people now run stuff like qmail or Postfix that set up their own
user IDs (qmail seems to want no less than 7, for the varying roles of
its components). The Hurd guys are trying to set up an
"authentication server" (which would manage user authentication and
the likes) which would run as a "nobody" user, and have _no_ access to
the rest of the system.

None of this is using the manifold-rings approach of Multics, but it's
certainly getting a tad more akin at least from the perspective that
the average system service _isn't_ necessarily going to run "as root."

That's a pretty big mouthful, to preface a pretty short question.

Are there some major insights vis-a-vis security that could get
usefully passed on to systems like Linux that could provide some
_real_ improvements in secureness, moreso than just "well, ACLs could
be pretty useful?"
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/advocacy.html
When marriage is outlawed, only outlaws will have inlaws.

Douglas H. Quebbeman

unread,

Dec 1, 2001, 8:18:19 AM12/1/01

to

<cbbr...@acm.org> wrote in message
news:HIXN7.18061$3i2.3...@news20.bellglobal.com...

> I am aware of one counterexample; TOPS-10 had a file sharing
> scheme where a daemon called FILDAE would, if an attempt to
> [somehow manipulate - read/write/delete] a file failed, look at
> an ACL "policy file" to see if the ACL info would grant the
> access that file permissions failed to grant. I preserved a
> discussion about this at <http://www.cbbrowne.com/info/fs.html>,
> which was wise, in retrospect, as Deja.com is no more.

Chris-

Google (groups.google.com) now has the Deja.com USENET archive
and is doing a pretty good job with it (except for the lack of the "original
posting format" option).

Regards,
-doug q

Anne & Lynn Wheeler

unread,

Dec 1, 2001, 11:27:57 AM12/1/01

to

cbbr...@acm.org writes:
> b) Capabilities.
>
> Capabilities are cool, because you attach them to programs, thus
> granting, to the program, the ability to access only what you set
> up the capabilities to grant access to.

tymshare did an operating system for ibm mainframe called gnosis
(which was spun-off when M/D bought tymshare and renamed):

keykos
http://www.cis.upenn.edu/~KeyKOS The KeyKOS System

misc. pieces from above:

U.S. Patent 4,584,639 - Covering the KeyKOS "Factory" The infamous
(and much lamented - at least by me) "Factory Patent", covering the
mechanism for secure sharing of programs among mutually suspicious
users.

===

The Confused Deputy (1988)

Sometimes program must run under a combination of authorities. This
leads to obscure bugs and security holes. This paper identifies the
cause of the problem, and points out some solutions. The paper is also
available in postscript form.

===

derivative work for intel platform
http://www.cis.upenn.edu/~eros/ EROS: The Extremely Reliable Operating System

random gnosis/keykos refs:
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?

--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/

Vincent F. Scarafino

unread,

Dec 1, 2001, 12:18:09 PM12/1/01

to

Seems to me an automatic update facility would be a great target for
mischief, too.

cbbr...@acm.org

unread,

Dec 1, 2001, 8:03:33 PM12/1/01

to

Anne & Lynn Wheeler <ly...@garlic.com> writes:
> cbbr...@acm.org writes:
> > b) Capabilities.
> >
> > Capabilities are cool, because you attach them to programs, thus
> > granting, to the program, the ability to access only what you set
> > up the capabilities to grant access to.
>
> tymshare did an operating system for ibm mainframe called gnosis
> (which was spun-off when M/D bought tymshare and renamed):
>
> keykos: <http://www.cis.upenn.edu/~KeyKOS The KeyKOS System>

> derivative work for intel platform <http://www.cis.upenn.edu/~eros/>

> EROS: The Extremely Reliable Operating System

I'm at least generally familiar with this work; once downloaded and
tried to compile EROS, with not tremendously successful results.
Apparently the sources are pretty touchy, and my C++ is pretty weak
:-(.

KeyKOS was kind of neat, providing a way of more strongly partitioning
pieces of VM / MVS / CMS systems; whether for good or for ill, that's
not where development effort is going these days. There are bigger
System 390 systems, at lower prices, with more power, than there ever
were, but the armies of COBOLers and PL/1'ers are definitely on the
wane.

EROS seems to have pretty much jumped from "nothingness" to "toy
system that demonstrates possibilities," but hasn't headed past that.

And when talk of EROS ever comes up, the question always is "So when
will the Unix simulator be ready?" The point of the exercise seems to
be to emulate Unix, and it's liable to do that in a bug-for-bug manner
that makes it of no value.

And it still leaves as a gigantic gaping hole the question of how to
design a suitable set of capabilities, of what "entry points" are to
be defined, and of how it is to determined whether a particular
process is permitted to go through such entry points.
--
(concatenate 'string "chris" "@cbbrowne.com")
http://www.cbbrowne.com/info/sap.html
Artificial intelligence, like fusion power, has been ten years away
for the last 30 years. -- Conrad Stack

Gene Wirchenko

unread,

Dec 2, 2001, 1:13:37 AM12/2/01

to

westin*nos...@graphics.cornell.edu (Stephen H. Westin) wrote:

>jra...@cascinc.com (Jeff Raben) writes:
>
>> how come there is nothing here about LLMPS (lincoln labs)
>> and MTS (Michigan Timeshare System) that originally ran on the /67?

^^^^^^^^^
"Terminal", at least, what I used.

>> The combination ran on many univerity machines.
>
>I think you mean UMMPS (the University of Michigan Multiprogramming
>System), the substrate for MTS. UMMPS may have been originally based

^^^^^^
"Supervisor", at least, what I used.

>on something from Lincoln Labs.
>
>I think the total count of installations never grew beyond about ten.

[snip]

>Other universities running MTS included Wayne State (in Detroit), the
>University of British Columbia, and the University of Grenoble, if

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes. That's where I used it. Later, Simon Fraser University
did. I think University of Alberta did, too.

>memory serves.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Richard Shetron

unread,

Dec 2, 2001, 8:40:02 AM12/2/01

to

RPI (Rensselaer Polytechnic, Troy, NY) ran MTS starting around 1976 on
a 360/67 under cp-67. I'm not sure when it was discontinued. It might
still be being run for some admin tasks on the 390. General student
access was stopped a few years ago as they started handing out laptops
to all incoming freshman. All the oncampus buildings including dorms
and student union have been wired for ethernet for years. About 4 years
ago I think they wired some of the nearer off campus fraternity/sorority
houses as well.

It was a great improvement over the previous 'interactive' system
called Alpha. Alpha basically turned a 2741 terminal into a card reader
for input and line printer for output. I still remember doing a LISP
project and having to hit enter twice after each line. One to end the
physical line and the second time so the batch LISP could see there
was no continueation character on the next line so it could process the
previous line.

I co-op'd at Griffiss AFB/RADC which upgraded from a 645 to a 6180
between my 75 and 76 co-op semesters. They kept the core boxes. I ran a
numerical application (unclassified) so I ran it on both the 6180 Multics
and the 360/67 under CP-67/OS-360. The Multics fortran compiler compiled
as fast as Watfiv (very fast compile, very slow run) and executed as
fast as Fortran-H (slow compile, fast run). According to the manuals,
the instruction times for similar instructions were about the same.
--
Richard Shetron mul...@ruserved.com mul...@acm.rpi.edu NO UCE
LEGAL NOTICE:Sender of UCE to this address agrees to pay me $500/email
plus any and all costs of colleciton.

kar...@watson.ibm.com

unread,

Dec 4, 2001, 3:46:30 PM12/4/01

to

In article <2dQN7.26094$cC5.2...@news20.bellglobal.com>,

cbbr...@acm.org writes:
>
>Gemini Computers' "Gemini Trusted Network Processor" was rated A1 in
>'94.
>
>Wang Federal, Inc. SCOMP Version STOP Release 2.1 was rated A1 in '84
>
>Only SCOMP _might_ have been an operating system, per se; MLS LAN and
>the Gemini system were both rated A1 as "Network Components."

The Gemini system, although rated as a "network component" was definitely
a general purpose operating system.