Code access security does not replace existing security; it is complementary. Code access security complements Windows security by describing the permissible behavior of code.
It is clear that Windows security describes what users and groups are permitted to do. If you are an administrator, any (unmanaged) code running while you are logged on can do anything that you can do as an administrator. The identified problem is that not all code originating from all locations can be equally trusted. If you write code on your disconnected, nonnetworked PC, you can trust it to do what you program it to do. The same is not true for code originating from someone else or, worse , somewhere else, like the Internet.
Code access security layers in permissions relative to what code is allowed to do, constrained by an administrable security policy and the origin, or zone, from whence the code originates. For example, by default, code originating from your machine has more privileges, and code originating from an intranet zone or Internet zone has fewer privileges.
Suppose, for example, you are logged in as an administrator. You, as an administrator, are permitted to modify or wipe out the registry. If you run some unmanaged code as an administrator, that code can wipe out the registry (or file system) too. Code access security works by setting a policy that dictates what code is permitted to do.
The relationship between code access security and Windows security is akin to the relationship between federal and state laws. Windows security represents federal laws, and code access security represents state laws. If the federal government outlawed the sale of alcohol, no state could make the sale of alcohol permissible. However, since the federal government currently permits the sale of alcohol, some states ”or smaller groups within states, such as counties and cities ”could prohibit or limit its sale. (I remember passing "Bernie's Last Chance" while driving south on Dixie Highway in Kentucky, then later encountering the same establishment as "Bernie's First Chance" while heading back north. Hazard County in Kentucky is a dry county, or at least it was when I lived there.) In other words, states can make laws that are more restrictive than federal laws but not less restrictive .
This is true relative to Windows security and code access security. If the Windows permissions provided to you limit the installation of software, for instance, then code access security cannot grant it. Windows wins. However, if Windows is silent on the issue of installing software ”for example, with administrative privileges ”then the code access security policy could still prevent software installation.
In short, the rule is that code access security can be more restrictive than Windows security but not less restrictive, and code access security applies these restrictions to code, not users, as long as that code is managed code. This raises the question: What is the difference between managed and unmanaged code?
Quite simply, managed code is .NET code, and unmanaged code is everything else. When you run a .NET executable assembly, a loader program loads the CLR into memory. All .NET code runs within the CLR. (Thus managed code is code run within the CLR.) Code access security and security policies are not applied to unmanaged code. Keep in mind, though, that managed code can run unmanaged code through COM Interop. Fortunately, the code access security policy allows you to specify whether or not managed code is permitted to run unmanaged code.
Naturally, then, code access security policy is very important for managed code that originates from very risky zones ”the Internet and intranet ”to low-risk zones like your disconnected PC. As a result, if you are building stand-alone applications that run on a single PC, especially one that is not connected, you can tolerate the relatively low risks of remaining a bit ignorant of code access security. However, the more connected you are, the more information you will need to acquire about security in general and code access security specifically .