Secure Coding mailing list archives

Why Novell should take on the 'type-safe platform' challenge


From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 10 May 2006 01:22:01 +0100

Dinis Cruz wrote:

The ones that I wish were listening are Novell and the Mono project.
The path to a type-safe platform could start there.

Following this comment made on the previous thread, here are the reasons 
why I wished Novell and the Mono project where listening to that 
conversation (note: an edited version of this post was sent directly to 
several Novell contacts who asked me 'What is it you wish we would 
listen to?' :

---------------------------------

Dear Novell

What I meant by my comment, is that there is an opportunity today (2006) 
for somebody (namely a company + community) to really grab the 
'type-safe' + 'sandboxing' flag and run with it.

Here is a quick analysis of where we stand today:

    - Vista failed to deliver a OS based on a type-safe platform
    - 99% (or close) of the .Net Framework and Java code is executed in 
an environment with no sandbox (i.e. executed: a) in Full Trust, or b) 
with the Security manager disabled, or c) with no verification). Given 
the amount of code deployed out there, there is no chance that a real 
change will occur any time soon. Currently there is no interest from 
Microsoft or Sun to address this issue and invest the time, energy and 
resources required to solve it.
    - Microsoft failed to make the paradigm shift from Full Trust to 
Partial Trust when they released v2.0 of the .Net Framework (which would 
had been the perfect time to do it)
    - There is good grass roots support for type-safety
    - There is a growing need to create secure and trustworthy 
applications (with growing support from Governments, Large Corporations 
and ultimately the end users)
    - Sandboxing at the OS level, like the one in Vista's 'Integrity 
Level / Privilege Isolation' and in Suse's AppArmour (sorry Crispin for 
not replying to your posts on the previous SC discussion about 
Sandboxing (it is on my to-do-list)) will NOT prevent exploitation of 
the user's assets (like for example the user's email). These techniques 
are designed to 'control' and 'Sandbox' unmanaged code, which is 
something that I don't believe can be done today. A short term solution 
(before we get to type-safe OS) would be to have environments like these 
(which do add some security protection to the OS) supported by a 
managed/verifiable environment responsible for executing the 
managed/verifiable  (potentially malicious) code.
    - Apple has an amazing OS (which I am using at the moment) but 
doesn't seem to be focused on type-safe / sandboxing issues too. Apple 
also seems to (like most of the Open Source community) think that it is 
immune to security vulnerabilities (just look at the way they handle 
security patches at the moment)
    - Novell has gained a huge amount of respect for its support for the 
Mono-Project and for its support for Open Source
    - Basically, Microsoft has lost the plot on Security and (as Gary 
McGraw says) is too focused on bugs and not on architecture. They 
(Microsoft) will have tough times ahead when Vista proves to be as 
secure as XP SP2 was.
    - IBM has seen the future and is re-organizing itself around the 
concept of 'delivering enterprise solutions on top of Open Systems and 
Open Architectures'

So, like I said above, there is a big opportunity for an Open Source 
project, lead by a major company and based on a solid platform, to lead 
the way in the move from unmanaged/unsafe code (where I am including 
Full Trust .Net code in this category) to managed, verifiable and 
type-safe code (which can be safely executed in Sandboxes and malicious 
activity easily detected / mitigated)

Novell and Mono fits this bill perfectly.

And it would also give mono an unique point of sell, since at the moment 
it is still a 'pour cousin of the .Net Framework'.

Ultimately the goal would be to build an OS on of top of a type-safe 
platform. But before that the user-land world needs to be conquered.

A lot of research and effort must be placed on how to create powerful, 
feature-rich and fast GUI applications built on type-safe code. This is 
something that can only be done by a large community focused on a 
powerful goal: *creating secure applications for execution on 
secure/sandboxed environments.*

Imagine if this idea could be developed to such a state where (on 
Windows) it would be safer to execute C# applications on Mono than on 
the .Net Framework itself! (another area where mono could do really well 
is in Hosting of Asp.Net applications (for example based on a Linux 
distribution of a LAMM environment, hosted by a VirtualServer or VMware 
host))

I believe that we are watching today the limitations, of both Open 
Source world (with its 'many eyeballs') and Proprietary Code (with its 
Secure Development Lifecycle) to create code that doesn't contain 
critical security vulnerabilities (i.e. both can't do it (with maybe 
some notable exceptions)).

What is needed is a new paradigm (well not that new if you ask Gary 
McGraw) that *creates a financial-model that rewards the companies that 
are able to create secure applications that can be executed on secure 
environments *(the idea is not to prevent bugs/vulnerabilities from 
existing, but to prevent the damage caused by their exploitation).

Ultimately all source-code will have to be released and made public (not 
necessarily on an Open Source format, but at least available to peer 
review and external (i.e. independent) analysis) , and again here Novell 
and the other Open Source development companies have an advantage.

The other major asset which the Open Source distributions have (and one 
which will be crucial in the future) is the centralized distribution of 
Software (i.e. packages). In the future we will need entities that 
certify the security of Software applications, which in an 
unmanaged-code world (for example: C++ & Full Trust .Net ) is almost 
impossible to do (i.e. say for sure that Application XYZ does not 
contain a keyboard hook and direct access to the Internet), but quite 
possible in a managed, type-safe and verifiable world.

Of course that more CLRs (with custom GC, Security managers, Class 
loaders, verifiers, etc...) will need to be build, since the 
requirements of a powerful Windows Application, are very different from 
an Asp.Net Form, which are very different from a Device Driver.

Looking forward to your comments,

Best regards,

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060510/8077a017/attachment.html 


Current thread: