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
Secure Coding mailing list (SC-L)
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Reply via email to