Chapter 8. Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy

for RuBoard

By Matthew Lyons

IN THIS CHAPTER

• Membership Conditions

• Code Groups

• Policy Levels

• Default Security Policy

Thus far in this section of the book, we have discussed how security impacts executing code. Hosts provide evidence when code is loaded and permissions are used to determine if executing code has the right to perform some privileged action. The point of security policy is to get us from where evidence is provided for an assembly being loaded to the position where permissions can be used to cause stack walks during execution of an application.

The point at which security policy is actively being examined is known as policy resolution. Policy resolution is part of what happens while assemblies are loading. After evidence is provided for an assembly, the .NET Framework uses the stored security policy to compute the set of granted permissions for that assembly. After the granted permissions ( otherwise known as the grant set or granted permission set ) are determined for an assembly, they play a key role in stack walks and other security actions performed while code is executing.

Security policy is the mechanism by which administrators and end users can express their level of trust for different code. For example, a very cautious user may not want any code running on the intranet to execute, while another user may trust code from a few Internet sites to perform all privileged actions it might try. Security policy allows these decisions to be expressed with many levels of granularity in between.

An important concept to remember throughout this chapter is that security policy is simply a way to map intentions to something the .NET Framework can understand. The intention of the previously mentioned cautious user may be to be as safe as possible while allowing .NET Framework code to still execute. The security policy of the .NET Framework cannot understand this simple sentence , so the intention must be "translated" into terms it can recognize. Intentions must be well understood by users to be able to perform this translation properly.

This chapter will cover the following pieces of security policy:

• Membership conditions ”The approach to group code into different "buckets"

• Code groups ”Basic intentions that map .NET Framework code to specific levels of trust

• Policy levels ”The way intentions of different parties (network administrators, a machine administrator, an end user, and a developer) are taken into account

• Default security policy ”A safe, but useful set of intentions that should suffice for most users

NOTE

In the RTM release of the .NET Framework, default security policy was set to allow limited permissions for code loaded from the intranet and Internet. In mid-January, Bill Gates announced the strong commitment at Microsoft for the Trustworthy Computing initiative, which is aimed at ensuring that Microsoft as a company will meet customers' needs and expectations around privacy, reliability, and security. As a result of this, the .NET Framework team reconsidered the default security policy for the Internet zone. In order to truly emphasize the conservative "locked down" default behavior encouraged by the initiative and requested by customers, they decided to release service pack 1 (SP1) to remove the ability in default policy for code from the Internet to execute. This chapter will discuss the default security policy as reflected in SP1.

for RuBoard