Multics history

[karger at watson.ibm.com (karger at watson.ibm.com)]

Peter and Olin make good points about Multics security.  Let me
recommend a paper that Roger Schell and I wrote a few years ago that
discusses a number of lessons from Multics that are
forgotten/ignored/unknown today.

Multics had very few if any buffer overflow problems for a number of
reasons.

Upwards growing stacks helped.  Most things being non-executable
helped.  Segmented addressing helped, because it made it very hard to
accidentally address something outside the current.

Using PL/I rather than C helped a great deal.  PL/I allows the same
low level access as C that you need for system-level code, but it has
several crucial differences. Strings and arrays are first class data
types.  References to them are NOT equivalent to doing pointer
arithmetic.  Even if stringrange and subscriptrange checking are
turned off, the compiler knows the maximum length of most strings and
arrays and generates code that stops writing to the string or array
when that length is reached.  If stringrange and subscriptrange are
turned on, then additional checking code is generated, but that wasn't
usually necessary!

Most Multics system-level code did not use the equivalent of malloc()
at all.  In fact, I think using it might have been explicitly
forbidden for system level code.  This was possible, because you could
easily allocate free memory in Multics by creating a temporary or
permanent segment.  The segmentation hardware would protect against
overflowing that memory, and if you put in the process directory, it
would be automatically garbage collected when the process terminated -
not by a traditional garbage collector, but by the entire process
directory being deleted when the process terminated.  The process
directory had a quota on it, so that you couldn't run the system out
of memory - only yourself.

Note - that is not to say that Multics was free of all security
vulnerabilities.  It certainly was not, but it was dramatically better
than almost anything in widespread use today.

The paper to look at is:

Karger, P.A. and R.R. Schell. Thirty Years Later: Lessons from the
Multics Security Evaluation. in Proceedings of the 18th Annual
Computer Security Applications Conference. 9-13 December 2002, Las
Vegas, NV: IEEE Computer Society. p. 119-126. URL:
http://www.acsa-admin.org/2002/papers/classic-multics.pdf
  

One other thing - before you send emails about how Multics was secure,
but it was bad for this or that reason, so it therefore it doesn't
count, please first take a look at Tom Van Vleck's web page about
myths about Multics.  

http://www.multicians.org/myths.html 

It's an amusing page to read, even if just for the war story about the
error message in Latin!

There is a LOT of bad information out there on the web about Multics
that simply isn't true.  Multics was certainly NOT a perfect system -
it had its flaws, but in all too many ways, the computer industry has
yet to catch up to what Multics could do back in the late 1960s!

Paul

====================================
Paul A. Karger, Ph.D.
IBM, T. J. Watson Research Center
Tel: +1 (914) 784-7294 (tieline 863)
Fax: +1 (914) 784-6205 (tieline 863)
Email: karger at watson.ibm.com
Mailing address: PO Box 704, Yorktown Heights, NY 10598, USA
For mail that cannot be sent to a Post Office Box:
Street address:  19 Skyline Drive, Hawthorne, NY 10532, USA