Web hosting companies offer a variety of plans that cover almost every real-word scenario. Shared hosting is usually the most economical choice for low traffic sites. A single physical Web server can run dozens of sites/applications, and it is important that one site cannot harm or affect all other sites on the same box in any way.

ASP.NET allows users to define trust levels, which describe what operations are permitted in a hosted environment. You can either use one of the preset trust levels - Full, High, Medium, Low, or Minimal - or can create a custom level. Full trust, which is the default, comes without any restrictions. It is therefore a standard practice for a majority of Web hosting companies to run customer sites in a medium trust environments. This is set in a global config file and cannot be overriden in your application code, ensuring that hosted applications do not interfere with each other or use protected system resources like the the file system outside the application root path, the registry and the event log.

Unfortunately, the default medium trust policy is often too restrictive for more advanced applications, as it doesn't allow reflection, serialization, access to outside Web services, and other standard ASP.NET techniques. Although in theory each of the "forbidden" techniques could be used to compromise the server security, a vast majority of Web developers uses them for perfectly legal and valid purposes. A discussion thread on stackoverflow nicely summarizes the potential security risks: "...most likely, it's at least in part a sales technique to get you to shell out for (semi-) dedicated hosting.".

Additionally, as .NET Framework's Code Access Security model has evolved, ASP.NET 4.0 Code Access Security has introduced several breaking changes. You can find a nice primer on Code Access Security, and its implications for .NET 4 are described here. It looks nice, but it comes with its share of problems. Be warned that a lot of rather straightforward code will simply stop working, often without a meaningful error message. For example, even with the customized medium policy that elevates the reflection permission, we used to get a lot of these error messages:


It turns out that you need to know exactly which .NET methods are decorated with the SecurityCritical attribute, since you cannot call them anymore if your calling methods are not marked as SecurityCritical or SecuritySafeCritical. Unfortunately, all code running in the medium trust is considered to be SecurityTransparent, and you get an exception. Again, it feels like that sort of scoping issue would be caught by the compiler... but no luck. Your application suddenly becomes hit by a bunch of runtime issues. Another example of how things can go wrong with CAS can be found in the LLBLGen support forum - a totally unrelated WinForms designer attribute needing FileIO permissions down the road caused us a lot of pain there.
The best diagnostic utility for this kind of scenarios turns out to be the VS2010 Code Analysis tool with Microsoft Security Rules turned on. It is far from perfect, and we are open to all comments and suggestions on how to make ASP.NET code compatible with medium trust.

Going back and applying everything we've learned to MonoX, we have realized that a standard medium trust environment is simply too restrictive for all functionality it offers. Note that even a simple scenario that uses any of the LINQ-related functionality in ASP.NET requires elevation of reflection permissions. Therefore, it is not a big wonder that MonoX needs reflection (for Web part enumeration and loading, accessing Web part framework internal methods, ...), serialization (for ViewState optimization) and Web permissions (for contacting third party services, including anti-spam sites and Amazon S3). We have put together a customized medium trust configuration file that can either be used as is, or in communication with your Web hosting support staff. You can locate it in the root of the MonoX installation folder, and is aptly named web_mediumtrust.monox.config. It is essentially a copy of the standard web_mediumtrust.config file from the .NET configuration folder, but with three key differences:


You can test your MonoX-based applications in medium trust by changing the trust level setting in the web.config file and switching the default level (Full) to this:


Setting trust level in this fashion will probably not be possible in the live hosting environment, since most hosting companies do not allow users to override their default settings. In any case, you will be able to communicate your requirements efficiently by mentioning the security requirements for MonoX based on the configuration settings listed above.

If all of this sounds too complicated, note that many of the high-profile shared hosting providers offer full trust ASP.NET environments at bargain prices. More details can be found in our hosting review article series.