Limitations of the .NET Framework Security System

for RuBoard

While the .NET Framework offers a very flexible environment in which to secure your code and takes every opportunity to make such implementations as simple and foolproof as possible, it will not do all of your work for you. The designers and implementers of code must be aware of the security subsystem's limitations.

For instance, the security system cannot divine the intent of code. It doesn't know "good" code from "bad" code. It merely knows how to take a set of administrator-supplied rules (policy), apply it to known facts about an assembly (evidence), and generate the set of permissions that describe the level of trust now assigned to that assembly (the grant set). Demands are applied mechanically against the assemblies of the methods on the call stack, without the security system ever really understanding what operations are being performed. The name FileIOPermission is suggestive of its function to a human reader, but to the security system it is just another abstract permission, policing access to another abstract resource.

It is all too easy to forget this and assume that the security system will cope with breaches that, in reality, it's not even aware have happened . For example, consider the following snippet of code:

 class PrivateFlags {     public int _flags;     [PrivateFlagsPermission(SecurityAction.Demand, Unrestricted=true)]     public void SetPrivateFlags(int flags)     {         _flags = flags;     } } 

It's obvious to a human reader that a mistake has been made; the author intended the _flags field to be private and accessible only via the SetPrivateFlags method when the caller possesses the requisite permission. But the security system understands none of this; it doesn't see a link between the public field and the protected accessor of that field at all.

There are times when the security is paranoid on your behalf , in order to catch common coding errors. This was covered in Chapter 7, "Walking the Stack," where we showed that the default action of a security demand is to check every caller on the stack for the required permissions. As careful as this is, it is not foolproof. It assumes that data from untrusted callers will be passed via method parameters in a call, for instance. So it will not spot untrusted data read from a file or over a network. And that is a fundamental limitation of the security system, because it does not (and cannot) understand what is really being implemented. It is the responsibility of the application designers and implementers to consider these aspects of security and to ask themselves , "How do I validate the data I'm reading from this file or validate the trust level of the provider?" The security system can't ask this question for you, though it may provide the tools with which to implement the answer.

The other fundamental limitation of the .NET Framework security system is that it is constrained to the framework itself. The trust level of unmanaged code outside the framework is unknowable to the security system (since unmanaged code does not come packed up in assemblies, it cannot apply the policy system to it). Unmanaged code is not constrained by the requirements of type safety, whereas verifiable managed code must meet these requirements and, in doing so, limit itself to a "sandbox" from which it cannot escape.

Consequently, access to unmanaged code from the managed world is controlled by a very high-level permission in the .NET Framework: SecurityPermission.UnmanagedCode . Holders of this permission are very highly trusted by necessity, since code with this permission can subvert the security system itself. Remember that the .NET Framework runtime is implemented as user mode code inside the same process in which managed code is run. The security of the model relies on access to the process address space being rigidly controlled by the runtime (this is where type safety comes in). This rigid control cannot be enforced on code running raw, unmanaged instructions (the operating system only protects processes from each other; it enforces no in-process rules).

Naturally, unmanaged code is still under the control of operating system security; if a request to delete a file is made, that request will be validated against the user account under which the process is executing. The .NET Framework is trying to solve a larger problem, though. It is trying to constrain not just the user, but the code that the user runs. If a script file downloaded from the Internet tries to delete a file, it is not enough that the user is allowed to perform the operation; the code must have that privilege as well. After all, many viruses will destroy the user's own files, a perfectly allowable operation under the operating system's rules. So you can see that unmanaged code, given that it is not constrained by the .NET Framework, must be used very carefully if you want to avoid nullifying all the additional protection the framework was designed to provide.

The same is true of data that comes from outside the boundary of the framework (that is, from outside the process). The framework cannot validate raw data read from a file or a network connection for correctness, since it doesn't understand what the data means in the first place. Even for structured data (a serialized object read from a file, for example) it can only validate that the protocols of that structure have been adhered to; higher-level inconsistencies may still exist.

Security is more fundamental than a simple enumeration of the places where security demands will be initiated. A security weakness could stem from an action as seemingly benign as passing an instance of a particular type of object out of a public API. Often, the simplest and safest approach to security is prohibitively expensive (in terms of performance), requiring subtler schemes and protocols that you must adhere to carefully in order to avoid problems.

for RuBoard