Code Access Security and ASP.NET

for RuBoard

Code Access Security is a process that allows or denies code the right to run from within a method. This could be code that you have a reference to from a third-party or code that you have written. As with any security mechanism, there is a set of guidelines to comply with that should be used to ensure that the code written uses only the permission set intended.

The first guideline is writing type-safe code. Type-safe code is code that accesses types in very well-defined , allowable ways. Type-safety really comes into play when considering the mobile environment. Code that is not type-safe may access memory blocks that it is not allowed to, resulting in a security exception on .NET. Creating type-safe code is not really a difficult task; it's really just defining your data types in a manner that the CLR will be able to verify as safe. To assist you with checking your code to verify that it is type-safe, Microsoft has provided a tool with the .NET Framework called PEVerify . PEVerify reads the assembly and verifies the information within generated MSIL files and associated metadata to be type-safe or not. As a rule, the CLR will not execute code that is not verifiably type-safe. This can be overridden, although doing so is not recommended. JIT compilation also relies on code to be type-safe, so by overriding this setting, you may be jeopardizing all other security settings associated with an application.

NOTE

For complete information on PEVerify and its use, type keyword PEVerify in the .NET documentation index.

The next guideline is familiarizing yourself with imperative and declarative syntax. Together, this is referred to as security syntax. The main difference in the two of these is that imperative security calls are made by instantiating a new permissions object, whereas declarative security calls are made through the attributes of an existing object. Certain calls can only be made imperatively, and certain can only be made declaratively , while most calls will support both methods . An example of when to use imperative syntax may be when you are not going to know if users need rights to access a file until they are in the application. During their work, they need no security context, nor do they need any special permission checks until they want to use your new function. When they attempt to execute the method, you imperatively check permissions to see if they can perform the task. Your code then routes the user to the appropriate response depending on the result of your permissions check. In declarative syntax, you make a request through the metadata of your application/class/method. For example, let's say you have created a permissions object called canDoEverything , and you are writing a new method that requires a validation from canDoEverything before proceeding. Declaring the canDoEverything class prior to any other method calls in your class requires that the user meet the requirements established in canDoEverything or he or she can do nothing.

Third on the list is requesting permissions for your code. Requesting permissions basically just lets the CLR know what your code needs to be allowed to do. Now here's the trick ”you can ask the CLR for certain permissions that your application needs (or wants) to run but, depending on the CLR configuration, it can still say no. The actual permissions needed by your assembly can be seen using the PermView tool. This tool analyzes your code/executable and reports the permissions needed to execute it. This would allow an administrator to modify an account to suit your needs without jeopardizing the rest of the enterprise. Another fringe benefit of requesting permissions for your code is that your code only gets the permissions it needs, thus reducing the chance that if something does go wrong and someone could add some malicious code to your unchecked buffer, it would only execute with the permissions needed for the assembly, and that is, hopefully, not an administrator. Know that if you are not in control of the permissions on the box executing your code, you must trap for trying to use permissions you do have and cannot get. A message box with the text of "Security Exception “ Method ~ of ~ failed" is not going to cut it.

Finally, there are secure class libraries. Basically, a secure class library is what you get if you follow the previous three guidelines. It is more an end result that states that your code is verifiably type-safe, uses security syntax, and knows what permissions it needs through making requests .

The ASP.NET application you are writing is by default set to run as the ASPNET user. While you can control what permissions this user has, it's not a bad idea to establish a separate user for an application. All code access permissions implemented in the .NET Framework can take a PermissionState value as an argument to their constructor. These principles can be applied from anywhere you can create a class.

for RuBoard