Secure execution.
Sunday, June 12th, 2005I couldn’t find a good reason for why I would need code level security, yet in Mono, until recently you couldn’t execute assemblies on another machine without direct user involvement on most of the primary platforms that Mono targets when designing a very basic distributed processing system.
In Windows, assemblies you might not know or have complete control over can directly be executed off a network share, from a webpage in IE (like an activeX control or COM object), or even on a webserver if you are hosting assemblies for use on a webserver. The ability to overwrite assemblies can be a concern in some cases as well. Microsoft made .NET handle this pretty well and has thier setup working for the vastly more complicated maze they have because of the amount of integration. .NET has in everything now and it’s included with every recent version of Windows.
Mono is growing on its ability to do the same, but didn’t start out in the same boat. In a Linux environment, very few pecies of software are going to be based on Mono and the framework comes pre-installed on very few systems. If Mono is installed, it usually supposed to be there and its entire setup is usually understood when its there. Also in Linux, it remains very difficult to execute an assembly without direct user interaction in the process. Hosting of assemblies for Mono for ASP.NET is still very limited right now as well, but if anyone where to do so, other methods of maintaining security are possible in Linux like in many other shared virtual hosting environments do already, because most systems for that are provided at a operating system level. It’s almost a fact that Mono can be almost as unique and Linux makes it a hard target and why security is still very high with Mono.
So where do security risks come up when you could just run Mono under and a secured user in Linux? It’s a very good question. The anwser is when you have code that can execute in the same application domain as a semi-trusted assembly. Only one Mono process for everything and some code might need higher security where other code maybe only partially trusted for execution. Mono then has to delgate how stuff runs. The case might come up when you might have a purchased component and you can’t review it’s source or when the assemblies could be loaded from a uncontrolled source like in the case of a distributed transaction system or when you might call and load an assembly dynamicly like with auto updated software or anything you can come up with.
The solution: Code Access Security (CAS), and good user policies is the most intelligent solution. If you can review the source, you can’t trust the code so you have to protect yourself. CAS is amazing. Conceptually if you think about it, the assembly would have to call base class libraries in the framework if it was going to do anything insecure, but in Mono you control everything. You have the source of the code its going to call, and you provide the framework for it. Because of that, anywhere it may call in the framework to do something, you can catch it. That is what CAS is.
Another system would be running a secondary app domain in another process with higher security and tunneling messages back and forth over some type of interprocess communication system (like .NET remoting or dbus). Security can almost be assured in this case but will cause a major drag in performance to make it work.
What does this mean? Mono has security in mind. What could be better when you are trying to prove to someone in managment that Mono is truely enterprise worthy? 
