Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
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 are lots of security decisions that can only be made several layers above the Operating system. An OS kernel (like Windows) can easily make a security decision based on the user identity (either allow or deny access). But that kernel will have a hard time in making security decisions based on the level of trust that we have in a particular executable or code (i.e. in creating Sandboxes which limit the functionality (i.e. permissions) available to that 'untrusted code'). The .Net Framework CAS (Code Access Security) when used to host applications that are executed in secure partial trusted environments, is a good example of an environment capable of securely execute malicious code. Eventually, some of the current functionality provided by the .Net CLR (Common Language Runtime) will have to be moved to the Kernel (for security and performance reasons) Is this like a firewall and IDS - just another layer we have to add due to ineffective and insecure OS's? The insecure OS is the one we have today which allow unmanaged malicious code to have full access to the user's assets (this applies to Windows, Linux and Macs). Are we dealing with symptoms or the real solution? Well I believe that Sandboxing (i.e. secure runtime environments) IS the solution :) Microsoft (and most of the Linux and Mac crowd) seems to think that they can build a secure and trustworthy OS that is able to securely execute malicious unmanaged. I (gently) disagree with this opinion, and argue that the desired level of security (and trustworthiness) can only be achieved via managed verifiable code. Dinis Cruz Owasp .Net Project www.owasp.net ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
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 younger folks among the SC-L audience, let me mention a few of the architectural strengths. There were no buffer overflows in the stack, because anything out of the stack frame was not executable. The ring-structured domain architecture and file system access controls permitted straightforward sandboxing. Dynamic linking and revocation were fundamental. Segmentation and paging enabled layers of virtual machines and protected virtual memory. The I/O system had virtual stream names, virtual I/O, and common device-driver software where appropriate, coupled with separate hardware for the input-output controller (GIOC). The programming language was the stark EPL subset of PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to have avoided some of the characteristic programming errors that are still common today. No software was written until there was an approved specification, with well defined interfaces and exception conditions that were explicitly characterized in EPL. And so on into a visionary sense of a future that has been largely lost for may perceived reasons, some of which are bogus, some of which are just seriously short-sighted. *** END SOAPBOX *** I'm sure this message may generate all sorts of Ifs and Ands and Buts. But the Butt we are kicking is our own. Cheers! PGN ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
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 it's good to get confirmation of some of what I think I've learnt.) No software was written until there was an approved specification, with well defined interfaces and exception conditions And here you come close, I believe, to one of the reasons this kind of security architecture is not more done. This kind of coding - heck, even just writing good specifications - is hard work, work that comparatively few people are competent to do. In all my years at this, I can count the number of times I've seen a really well-defined specification on the fingers of one hand. (The case I usually cite is the VAX Architecture Reference Manual, which is carful to call out all the cases where the behaviour is UNDEFINED or UNPREDICTABLE, those being technical terms defined early in the document, and to cover every possibility with defined behaviour or one of those.) Almost everything has holes, cases where the spec is silent; this is not the way to produce solid designs. In many cases a shaky design is no big problem (so your solitaire game crashes now and then, so what?). But in other cases it can be quite disastrous, with the kind of consequences everyone here surely knows far too much about. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
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 data beyond the current activation record--in contrast with most linear addressing systems where an overflow is almost always able to reach important values like the return address. It is sobering to reflect how much of the current state of our art was laid out clearly in 1969 by Peter's own The Role of Motherhood in the Pop Art of System Programing paper and by the 1973 Saltzer/Schroeder paper The Protection of Information in Computer Systems. These are always worth a read: http://multicians.org/pgn-motherhood.html http://www.cs.virginia.edu/~evans/cs551/saltzer/ -- Olin Sibert At 01:17 PM 3/29/2006, Peter G. Neumann wrote: 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 younger folks among the SC-L audience, let me mention a few of the architectural strengths. There were no buffer overflows in the stack, because anything out of the stack frame was not executable. The ring-structured domain architecture and file system access controls permitted straightforward sandboxing. Dynamic linking and revocation were fundamental. Segmentation and paging enabled layers of virtual machines and protected virtual memory. The I/O system had virtual stream names, virtual I/O, and common device-driver software where appropriate, coupled with separate hardware for the input-output controller (GIOC). The programming language was the stark EPL subset of PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to have avoided some of the characteristic programming errors that are still common today. No software was written until there was an approved specification, with well defined interfaces and exception conditions that were explicitly characterized in EPL. And so on into a visionary sense of a future that has been largely lost for may perceived reasons, some of which are bogus, some of which are just seriously short-sighted. *** END SOAPBOX *** I'm sure this message may generate all sorts of Ifs and Ands and Buts. But the Butt we are kicking is our own. Cheers! PGN ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
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 important values like the return address. This is only because the libraries used store later characters in a string at higher addresses (as compared to earlier characters). If the string libraries stored strings the other way around (with the earlier characters at the higher addresses), downward-growing stacks would have exactly this kind of buffer overrun protection. Hmm, I wonder if there's something useful lurking there. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
