Structure of the .NET Framework Security System

for RuBoard

Now that we've covered the basics of security responsibilities, let's see what the .NET Framework provides in the way of support.

Figure 23.1 shows how the runtime acts as a layer between the client code and the operating system, adding (from the perspective of security) the concept of code-identity “based security checking.

Figure 23.1. NET Framework layering from the security perspective.

Notice that the lowest , most fundamental level is the operating system itself. This is not just a case of the .NET Framework utilizing general operating system services as part of its implementation (though it certainly does this). Rather, we mean to show that the security checks and constraints put in place by the framework are in addition to those provided by the operating system.

Say a developer writes the following code fragment:

 FileStream file = new FileStream("c:\foo.dat", FileMode.Open, FileAccess.Read); 

Execution of this code will cause the .NET Framework security system to initiate a demand for FileIOPermission with read access to c:\foo.dat . The demand will walk the stack and verify that every assembly involved in the call chain has been granted the aforementioned permission. That takes care of the code access security check.

The implementation of the FileStream constructor will at some point call the Win32 function CreateFile to let the operating system access the file. At this point, the user credentials of the process or thread will be checked against the protections on the file (using Win32 ACLs). So user identity checks are performed as well.

Therefore, for the FileStream operation to succeed, the file must be accessible to both the user making the call and the managed code with which the call is made.

Registry access is the other major area where the same dual access check behavior is exhibited. In future versions of the framework, it is possible that managed wrappers around other access-controlled operating system resources (such as processes or shared memory) will become available and follow the same pattern.

The framework sometimes checks code access to operating system resources that don't have any corresponding notion of user access checks. Examples include the use of environment variables and the ability to manipulate UI elements such as dialog windows . This gives a system manager or user much greater control over a managed application than the traditional unmanaged world allows. For example, default security policy prevents a downloaded Internet applet from determining the user's account name from the environment. The operating system would allow such access since environment variables are essentially private to a process, and it seems reasonable that a process should always be allowed to access its own data.

The next category of security checking is for resources that are entirely managed, with no unmanaged counterpart . Examples include access to isolated storage or the reflection subsystem, and the ability to control the .NET Framework security system itself (using, for instance, SecurityPermission.ControlEvidence or PrincipalPermission ).

PrincipalPermission is interesting in that it provides the basic infrastructure to implement security access checks that are based on arbitrary data associated with the thread of execution as opposed to the identities of assemblies on the current call stack. This is similar to the way in which the operating system tracks user identity using tokens, and is referred to as role-based security within the managed world. Role-based security is a fundamental part of ASP.NET's security implementation.

The .NET Framework class libraries provide a rich set of resource access APIs that already implement the required security checks. In the preceding examples, we already touched on some of them: file, registry, reflection, and so on. It's important to note that this alone is not enough to ensure secure code, however. Such resources must always be treated responsibly to avoid creation of security holes. For instance, if a trusted method opens a file and then passes the file handle out to an untrusted caller, it's important to realize that access to the handle is not guarded by any further security checks (all security checks are centered on handle creation for performance reasons), so you might be introducing a security hole.

Sometimes it might be necessary to explicitly call the security system in order to secure some aspect of your code. The .NET Framework exposes a number of APIs to demand and manipulate permissions, permission sets, policy, and the like. For instance, a new public method that exposes functionality to access the unmanaged world might incorporate the following code to ensure that callers have the required level of trust:

 new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Demand(); 

The .NET Framework security system provides the ability to extend the code access security model as well. If your application creates a new resource to which code access should be restricted, it is a simple matter to implement a new permission to represent the level of access granted and the corresponding policy extensions to decide under what conditions that access should be granted. Since the .NET Framework is based on an object-oriented model, extending the system in this manner is usually just a case of subclassing a type or implementing an interface.

To recap, the .NET Framework security system provides basic infrastructure in terms of code access and role-based security (the means to represent levels of trust and then check those levels at runtime). On top of this, the framework libraries provide common permission types ( FileIOPermission , for example) and enforce access checking on the resources they expose. Underlying all of this, the operating system continues to enforce the same access controls it always has. Users of the framework can leverage existing permissions to provide their own access control or implement entirely new permissions and policies.

for RuBoard