Gallery

.NET security

Posted on 26 Jul 2006 at 15:16

Thomas Lee looks at the security architecture of .net and delves into code access security

To ensure adequate performance, detailed authorisation checking isn't performed on every access to a resource, but only at the time the resource is first "opened". When this occurs - for example, when a file is opened for editing - the opening application asks for a certain level of access (read only, read/write and so on), which gets checked against the access control list. The only actions that can be subsequently performed on that resource are those that were specifically requested, which means a user who has full rights to a file might open that file with some subset of those rights, and is then only allowed to perform that subset of operations. Even though that user had write access to the file, Windows wouldn't allow writes to it unless the file was closed and then reopened with read/write access.

This security model has worked well for many years, but applications are increasingly made up from a variety of components with many different sources, so a more granular approach to security is needed.

Code as a security principal

Most IT professionals are now familiar with the NT approach to security and its many subtleties. One of its weaknesses is that it's only the user who's the subject of authorisation and trust. If I'm a trusted user, I can obtain code from anywhere and run it, even if that code is malignant. Under .NET, Microsoft provides all the user-based security features described above, but goes one important step further by making code a security principal as well as the user. This means the operations that code is allowed to perform may depend on authentication of the code itself, not merely of the user who ran it. This is known as Code Access Security, or CAS, and it means you can define what things a particular bit of code is allowed to do, irrespective of who's running it, providing you with a fine-grained level of security.

CAS is based around three core concepts:

• Evidence: the way a piece of code proves it's what it claims to be.

• Policy: what you allow different sets of code to do.

• Permissions: what the code can actually do, based on both evidence and policy.

Evidence is used to verify the identity of code, at the level of a .NET assembly, and forms the basis for CAS. A given assembly may contain up to seven types of evidence that can provide answers to the key questions: where did this assembly come from and who wrote it?

The first four of these evidence types identify the website, URL, zone and application directory of the assembly (these evidence types are typically used in web applications where assemblies may originate from all over the world). The next two types, the strong name and the publisher certificate, help to identify the author of the assembly. The final piece of evidence, the hash, helps to identify the particular compilation of an assembly. Although .NET ships with just these seven evidence types, developers can extend this scheme by providing their own evidence, and can extend the policy system to cater for such new evidence types. This, however, is way beyond the scope of this article, where I'll concentrate on the built-in evidence types.

Not every assembly contains all these forms of evidence - a locally loaded assembly wouldn't have a site, while an assembly that hasn't been created with a strong name obviously won't have one. The Assembly Loader is the .NET component responsible for loading assemblies, and hence for gathering evidence at load-time based on where the code is being loaded from, as well as from the metadata within the assembly.