HISTORY
In the wars that raged to produce extensible code, Microsoft pulled a hail-mary by releasing ActiveX. It sounded cool, but roughly all it was was a slap-back to Java's virtual machine (JVM) applet engine which allowed an installable library to run on a person's machine, and to be executed and controlled via remote procedure call (RPC). An example of this might be a chat window. Both clients would download an applet and use a reflection server to traverse NAT.. etc. The application would call out to the server, and the response would encapsulate a command to activate code. Newer versions of this include evolutions that bear on technologies like SOAP, Browser PUSH, etc.
Microsoft needed to release their own ability to give RPC access to COM libraries. Hence, the hurried release of ActiveX. However, in the process, insufficient thought was given to the paradigms in which this technology would be deployed. While Sun, by defualt, had to think through the concerns to make their JVM portable to different systems, Microsoft's ActiveX simply had the task of linking the RPC functionality to COM applications.
The problem was introduced in the following paradigm: malware. Now, using the relatively unsecure ActiveX component, a site could pass an object which would call for the reformat of hard drives, for example, and claim that it was actually graphics enhancement or something else benign. As long as the user running the ActiveX has sufficient privileges to execute the code, they could run the program and viola! No files. Big problem.
Enter CAS. With the release of .NET 2, Microsoft produced Code Access Security which adds a layer of protection.
HOW IT WORKS
When you execute code, your machine checks the assembly you are executing and sees what level of privileges are necessary to run. Every conceivable condition can be constrained. For example:
Code on a network share on HOST1 that requests access to a SQL Server, being accessed by the .NET framework running on a HOST2 can have a different security zone/attribute/setting than if the same example was running on a local instance.
A brief run-down of the process is as follows:
1. .NET looks at a particular strongly-named assembly, decrypts the SHA1 info wrapper, and reads the levels of trust requested by the assembly.
2. .NET then checks the zone that the particular assembly qualifies for. So, if it was a DLL on a network share, it would be a part of a local-intranet zone.
3 .NET looks at its local machine's rules for that zone, and makes sure that all the levels of permissions the DLL needs, are allowed for that zone.
4. .NET opens access to the assembly.
Strong-naming
So, the question then is, what is strong-naming? This is the lynch-pin for developers. In order for the developer to deploy the code into production, they need to be able to wrap the assembly in a strong-name that the executing .NET environment can evaluate. This includes a key-pair encryption to centralize the control of the build.
A strong naming process essentially:
1. Reads the contents using reflection and checks for the levels of CAS necessary to execute to completion on all forks and levels.
2. Encrypts the assembly with the key provided.
What problem you usually run into in development:
You are going along, minding your own business, and all of the sudden, code that should work and function perfectly in Visual Studio, suddenly says stuff like:
Unknown tag
or
Cannot load assembly
While a number of things, including too much coffee or too little talk radio could be the chief contributor, often it is because your code has moved around into different code zones, or that you have not strongly named your assembly.
So, the answer is to configure CAS, using caspol.exe
If you are using Visual Studio, open the vs command prompt, and the environment variables will be loaded to allow you to use this command. If not, you need to install the .NET SDK.
A couple of useful commands are:
Gaining access to code on a network share by setting it as group and setting the group access to FULL TRUST:
caspol -m -ag 1.2 -url file://\\{servername}\{sharename}\* FullTrust
Gaining access to a non-strongly named assembly on a network share:
caspol -m -ag 1.2 -hash SHA1 -file \\{servername}\{sharename}\{dirpath}\{filename} FullTrust
I will include more on this post as I come up with them.
No comments:
Post a Comment