Managed Code and Runtime Environments - Another layer of added security?

[dinis at ddplus.net (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 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/c83e1e19/attachment.html