What Are Trust Levels
Trust levels let you define security rules. They define the types of operations an application can perform, for example reading from disk, accessing the registry, change file permission, modify system files etc.
Each trust level has an associated policy file, except for Full trust. When an application runs with Full trust, code access security places no restrictions on the resources and operations that the application is allowed to access. Access to resources is based on operating system security and Windows access control lists (ACLs). Full trust is mapped to an internal handler, so it is not possible to edit the user rights to perform operations for an application. Full trust is effectively the absence of an application domain policy, and therefore it never has an associated policy file.
To protect ASP.NET applications, you can restrict access to resources and the operations that they can perform. You do this by setting the <trust> element to a predefined trust level.
What Do the Trust Levels Allow
Full
Applications that run at Full trust level can execute arbitrary native code in the process context in which they run. Because of the inherent risks that come with running in Full trust mode, this mode is not recommended in a shared environment except when every Web site uses its own application pool and application pool identity.
High
Code in High trust applications can use most .NET Framework permissions that support partial trust. This mode is often appropriate for trusted applications that you want to run with fewer user rights in order to mitigate risks. For example, this level provides the same access as Full trust, but restricts access to unmanaged code and COM interop.
Medium
Code in Medium trust applications can read and write in its own application directories and can interact with Microsoft SQL Server™ databases. However, by default, the user rights that are needed to access OLE DB and ODBC are not granted to Medium trust applications. Medium trust is the recommended setting for a shared server, because it allows connections to SQL Server databases and restricts most other user rights to the application root structure.
Low
Code in Low trust applications can read its own application resources but cannot make any out-of-process calls, such as calls to a database, to the network, and so on. By using Low trust, you effectively lock applications down to their application directory and remove all access to system resources.
Minimal
Code in Minimal trust applications can execute but cannot interact with any protected resources. Minimal trust may be appropriate for mass hosting sites that want to support dynamic generation of Hypertext Markup Language (HTML) and isolated business logic.
What Trust Level Should Be Allowed In Shared Enviroments
In the Microsoft Shared Hosting Deployment guide this recommends that shared hosting servers are setup to run in a Medium Trust enviromnet which is the way that we have setup our shared hosting enviroment.
Trust Level Recommendations for Hosters
The following are general recommendations for trust levels for shared-hosting sites:
Hosters should not use Full trust in shared-hosting scenarios. For Web servers that are Internet-facing, Medium trust is recommended. When applications run under Full trust, they are fully trusted on the server. Even if they are isolated by process and even when permissions are limited, applications can access each others’ content, and they can access many system resources, such as the registry and event logs.
Each Web site should be run in its own application pool.
Permissions for access to the file system should be locked down for each Web site
What are the consequences of running full trust in a shared environment
Running in Full Trust is a dangerous when working in a shared environment because it allows one web application to interact with the file system of other web applications on the same server, if an ASP.NET application is running in Full Trust, there’s nothing to stop them from reading, creating, modifying, or deleting files in your web application’s file system
Full Trust allows .NET code run within sites to access and control the entire file system this also applies to the registry of the server (!!!).
As an example of this would be where a users site is porly coded and a malisus user injects code or a file is uploaded to thier space due to poor FTP password which then reads the config files for all databases on the server and connects to them enabling them to view important information like customer names, addresses, credit card details etc, they would also have the ability to remove all files or format a drive, so as you can imagine this isn’t good practice for a shared hosting environment.
Is a full trust environment available?
Although we do not recommend using a full trust server in a shared environment we have built a server which can accommodate this. Because of the problems above we don’t recommend that any important or sensitive data is hosted or linked to from any full trust server (from us or any other provider) . However provided customers accept the unavoidable risks of using this type of service we can still provide services as a last resort. An additional precaution we take is that you cannot signup directly to this server and all prospective users have to be UK based and fully vetted and whilst this will not protect against intrusions from any other users vulnerable code on the same server by outside 3rd parties it does help the risk of fraudulent sign ups accessing the entire server and its contents. However please AVOID at all costs full trust in a shared environment if you can.
