Chapter 25. Implementing a Secure Assembly

for RuBoard

By Rudi Martin

IN THIS CHAPTER

  • Using Existing Security Mechanisms

  • Implementing Your Own Permissions

  • Working with Strong Names

In previous chapters, you've looked at high level architectural and design issues crucial to producing secure code. Now we're going to delve down deeper into the low-level details of actually implementing such code. This chapter is focused on writing code that explicitly interacts with the .NET Framework security system (the implicit facets of writing code that doesn't give away trust can't really be dealt with at such a low level ”they're very dependent on the exact nature of your product).

This chapter seeks to acquaint you with three broad areas of coding with the .NET Framework security system:

  • Working with the basic representations of trust (permissions and permission sets) ” The difference between imperative and declarative security operations and how to use them.

  • Implementing your own permission type ” The difference between code access security and non-code access security permissions will be explained here, as well as the role of permission attribute classes in declarative security.

  • Strong naming your assemblies ” Including key pair generation, the mechanics of applying a strong name to various types of assemblies and how to set up a system to deal with delay signed assemblies.

A couple of notes before we begin:

In the following sections, we will often refer to standard .NET Framework permission types ( RegistryPermission and the like). The majority of these permissions live within the System.Security.Permissions namespace in the mscorlib assembly, so we'll omit this information for brevity. If we refer to any type or enumeration based in a different namespace and/or assembly, this will be noted in the text.

Often, in the interest of using a well understood example, we'll look at code snippets that demand FileIOPermission and other standard permissions. Use of the standard permissions in this manner will be reasonably uncommon ”the low level access routines in the .NET Framework already demand such permissions. Even if you're providing an intermediate layer above these, the stack walk mechanism will take care of checking the permissions of both your code and your caller. The only occasions in which it becomes necessary to think about demanding standard permissions yourself are when using the Assert operation (discussed in Chapter 7, "Walking the Stack") or calling methods decorated with declarative LinkDemands (discussed in the following sections).

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net