Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-04-06 Thread Dinis Cruz
Michael S Hines wrote: Which brings us to the point of asking why we must have this run time environment to protect the computing resources. Why isn't this a function of and included in the Operating System code? We need to have these layers (i.e. more than one) because there

Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-03-29 Thread Peter G. Neumann
Der Mouse is barking up the right rathole. *** BEGIN SOAPBOX *** Having cut my security eye-teeth in Multics from 1965 to 1969, I am continually drawn back into discussions of what Multics did right that has been systematically (!) ignored by almost all subsequent operating systems. For the

Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-03-29 Thread der Mouse
Der Mouse is barking up the right rathole. :-) That's a lovely mangled metaphor. And, thanks for the kind words; I'm glad to see I'm not totally out to lunch. (I haven't been at this for as long as you have - you write from 1965 to 1969, during which time I was at most five years old - and

Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-03-29 Thread Olin Sibert
While we're on Multics lessons, let's not forget upward-growing stacks (which were a natural consequence of the segmented addressing architecture). Multics code was not immune to buffer overflows, but in most cases the effect was blunted because the out-of-range index values could only affect

Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?

2006-03-29 Thread der Mouse
Multics code was not immune to buffer overflows, but in most cases the effect was blunted because the out-of-range index values could only affect data beyond the current activation record--in contrast with most linear addressing systems where an overflow is almost always able to reach