Secure Coding mailing list archives
Multics history
From: karger at watson.ibm.com (karger at watson.ibm.com)
Date: Thu, 30 Mar 2006 10:43:32 -0500
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
Current thread:
- Multics history karger at watson.ibm.com (Mar 30)