Code Access Security (CAS) For Cloud Applications

Code Access Security (CAS) For Cloud Applications lets NOT Trust the Developers

    <trustLevel name="Full"    policyFile="internal"/>
    <trustLevel name="High"    policyFile="web_hightrust.config"/>
    <trustLevel name="Medium"  policyFile="web_mediumtrust.config"/>
    <trustLevel name="Low"     policyFile="web_lowtrust.config"/>
    <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>


Today's highly connected computer systems are frequently exposed to code originating from various, possibly unknown sources. Code can be attached to e-mail, contained in documents, or downloaded over the Internet. Unfortunately, many computer users have experienced firsthand the effects of malicious mobile code, including viruses and worms, which can damage or destroy data and cost time and money.

Most common security mechanisms give rights to users based on their logon credentials (usually a password) and restrict resources (often directories and files) that the user is allowed to access. However, this approach fails to address several issues: users obtain code from many sources, some of which might be unreliable; code can contain bugs or vulnerabilities that enable it to be exploited by malicious code; and code sometimes does things that the user does not know it will do. As a result, computer systems can be damaged and private data can be leaked when cautious and trustworthy users run malicious or error-filled software. Most operating system security mechanisms require that every piece of code must be completely trusted in order to run, except perhaps for scripts on a Web page. Therefore, there is still a need for a widely applicable security mechanism that allows code originating from one computer system to execute with protection on another system, even when there is no trust relationship between the systems.

More on CAS:

Although it can seem daunting to try to move a web application developed under Full Trust to Partial Trust, it is actually easier than it seems.(What a Pain) The idea is to make the web app as ‘dumb’ as possible, moving business logic to a facade assembly and using Assert statements to stop the stack walk. A custom permission helps to authorize upstream code.

This approach means that any malicious code uploaded to the web application folder is restricted by the lower trust level, and the security policy also meets the required baseline. At the same time, the functionality of the application has not been altered.

CAS defines permissions sets operations that can be done by a set of code. To do this, CAS identifies and characterizes the application code so the appropriate permissions for that code can be determined. So defining how you want your code access security to work is all about defining what you want an application to be able to do and not do and then telling .NET how to figure out whether the code gets the permission set to work.

What I Think:

I think CAS is a good system, but it is not completed, or provides many options (only 5) for Cloud or On Demand Applications Smart Security, it in fact creates more obstacles than protecting the web server and network. If your application has bad code and allows code injection you have a lot more problems than what this tries to help. Plus I like Smart Web Applications for many reasons. Most Hosting Sites uses the Medium Trust level for their Web Hosting Packages. So I love the "Lets Develop for the Medium Trust Level".  Here are the 5 Trust levels for On Demand Applications we will need a lot more than the 5 listed below.

Trust Level Key Capabilities and Restrictions
Full No restrictions imposed by code access security.
High No unmanaged code.
No enterprise services.
Can access Microsoft SQL Server and other OLE DB data sources.
Can send e-mail by using SMTP servers.
Very limited reflection permissions. No ability to invoke code by using reflection.
A broad set of other framework features are available. Applications have full access to the file system and to sockets.
Medium Permissions are limited to what the application can access within the directory structure of the application.
No file access is permitted outside of the application's virtual directory hierarchy.
Can access SQL Server.
Can send e-mail by using SMTP servers.
Limited rights to certain common environment variables.
No reflection permissions whatsoever.
No sockets permission.
To access Web resources, you must explicitly add endpoint URLs—either in the originUrl attribute of the <trust> element or inside the policy file.
Low Intended to model the concept of a read-only application with no network connectivity.
Read only access for file I/O within the application's virtual directory structure.
Minimal Execute only.
No ability to change the IPrincipal on a thread or on the HttpContext.

Comments are closed.