10. App Domain Permissions – Full Trust
Main
Foo
App Domain Permissions - Internet
Bar
File Read
11. -Heterogeneous App domain not possible now
- Assemblies with lower trust level could upgrade
themselves to a higher trust level by calling partially trusted
assemblies
-App domains previously had to be loaded after CAS was in place.
12.
13.
14.
15. Static
Analysis Possible
Sandboxing Easier
No permission set overlap due to heterogeneous
app domains
Permission grant sets not machine dependent
Assembly with a lower trust level can not call an
assembly with higher trust level and upgrade
Editor's Notes
Code access security is not implemented to prevent you from performing illegal operations through your code. It is implemented to make sure somebody using your application (website/dll/…) does not get privilege to perform an illegal operation. For example, somebody could upload a file containing malicious code to your website running under full trust. If this file is uploaded to the server root and made available through a link, the user could simply access the link and run the file.
Every application (website/dll…) can have a certain set of permissions attached to it. For example, if you have a simple webpage that performs currency conversion, it does not need file dialog permissions. However, a form that allows you to upload your profile picture on facebook would need file dialog permissions. Every application can be analyzed to figure out the exact and minimal permission set required for proper functioning.
While defining code access security, the first thing to set up is permission sets. New permission sets can be created as per requirements or existing permission sets can be used for defining the boundaries of your application. Some of the existing permission sets that are created by default are shown. A permission set can also be empty – indicating that the application(s) to which this permission set is assigned has no permissions at all. Such an application would not be able to run.
In order to assign a permission set to an assembly, certain criteria has to be met. For example, I can say that I want permission set “Everything” to be assigned to all local applications (running from my own system). The runtime security now has to figure out whether an assembly that is trying to run is local. Thus, there is a need for attaching some sort of metadata to all assemblies, which acts as evidence for that assembly. The assembly has to provide evidence of before runtime security judges it and assigns permissions to it. This metadata can include the Application Directory, Publisher, URL (from which the application is running), Site, Zone, Hash, and SN – as shown.
The permission set along with the membership condition (evidence needed to deserve that permission set) form a code group.
As discussed, when an assembly tries to run, it’s evidence is compared with the membership conditions and accordingly, the appropriate code group and its permission set are assigned to that assembly.
Some of the drawbacks of this security model (followed till.NET 3.5) were:Security policies had to be set independently for all systems. Thus, if your application was moved from one system to another with different CAS settings, there were chances of your application not working.Even if the default settings for CAS were used, there were chances that moving your application from a system using .NET 1.1 to the one using .NET 2.0 would break it.Moving an application from the local system to a share on the network could also change the permission set assigned, as then the application evidence would change to reflect the “network” zone instead of “local”.
In CLR 4, the permission check is now performed at the host level instead of the CLR level. Policies are no longer validated at the CLR level. If the host assigns a certain set of permissions to an assembly, the CLR accepts the same. Some examples of hosts are ASP.NET and SQL CLR. These hosts are now responsible for loading their applications in appropriate sandboxes, which have appropriate permissions assigned to them.
Earlier (.NET 1.1/2.0/3.5) when the file read operation in App Domain B was encountered, a permission check used to be stack traced right to the Main function of App Domain A. Not so now. For CLR 4, an App Domain independently has its own permission sets. Thus, for CLR 4, when the File Read operation for App Domain B is called, the permission stack trace would check permissions on Bar, Domain B, and then stop. If either of the checks along the stack trace fail, this file read operation would not be permitted.
These are the transparency levels for CLR 4. These can be compared to full-trust and partial trust. However, every piece of code can now be one of the three:Transparent (minimal permissions assigned, highly un-trusted)Safe critical (bridge between transparent and critical code)Critical (maximum permissions assigned, thus, most trusted)
According to the new CAS model, a piece of code that is security transparent (un-trusted and with least permissions) cannot directly call a Security Critical (full trust) code. The security safe critical code acts as a bridge between these two types of code. Safe critical code generally contains all verification logic which ensures that a piece of security transparent code that is trying to call a security critical code actually deserves to be permitted. Thus, if a security transparent code does not have file I/O permissions and it is trying to call a security critical code which does have these permissions, this request would not go through. A piece of code is not allowed to upgrade it’s permission set.
