Entering a New Paradigm: Code-IdentityBased Security

for RuBoard

Entering a New Paradigm: Code-Identity “Based Security

User -identity “based security systems have been very successful in regulating access to resources, such as the files and folders maintained by the operating system, or to a database in Microsoft SQL Server. However, there is a fundamental drawback to user-identity “based security ”by design, it operates at the granularity of user identity. All code running on behalf of a user is executed with the same access rights. This does not allow for trust distinctions between code itself. You may wonder why this is necessary. Certainly in the past, when desktop machines were not interconnected to each other or to the Internet and all software needed an explicit install action on behalf of the user, it typically presented few problems treating all software running in a specific user context as having the same access rights. However, in a world that does not consist of disconnected desktop machines anymore, but in which computers are typically networked, it is not true that all code run on behalf of a user should be treated the same way. Consider the following scenarios illustrating that not all code running on behalf of a user should be treated as equal:

• An administrator has written a security configuration tool and installed it on the local hard disk. In the absence of any security system other than OS security, if both applications were run, he browses to a local intranet site containing managed control by a publisher he has never heard of. If both applications were run, they both would execute with administrative privileges, having the right to modify system files and registry settings, for instance. However, the user can have more trust in the tool he wrote and installed himself, as opposed to the application about whose origin he does not know anything. Both are given the same potential for doing harm by user-identity “based security systems because they both run on behalf of the same user.

• A user wants to run various applications from the company's intranet (such as a chess application or an accounting database). By default, he does not want code coming from the intranet to access his local hard disk to maintain privacy of the data in his user profile directory. He also regularly runs a word processor from the local computer that he wants to have access to the user profile directory in which he keeps his documents. User-identity “based security systems could not answer the demands of the user. The administrator could set up the user-identity “based security policy to fully deny all applications run on behalf of that user access to the user's profile directory or, conversely, to grant it to all programs run on behalf of the user. User-identity “based security systems, such as the Windows Access control settings, do not work at a level of granularity allowing for some of the user's applications to have more access rights than others.

• An administrator determines that only programs of a certain software publisher should run when executed from the intranet or Internet. User-identity “based security systems would be categorically inadequate in expressing this constraint, because the information user-identity “based security systems use to make authorization decisions is not information about code itself but the user who runs it.

These are just a few of the possible scenarios in which user-identity “based security systems turn out to be insufficient to meet a particular security configuration and enforcement requirement. In general, the main problem with user-identity based “security systems is that all code run within the same user context is executed with the same rights to access protected resources. In a world in which the trustworthiness of the origin of a particular piece of code can vary widely, this can lead either to overrestrictive security policy settings or potential security holes if only user-identity “based security is available. However, the .NET Framework ships with a code-identity “based security system (Code Access Security [CAS]) that can answer the needed security requirement. First, you may ask exactly what defines code-identity “based security systems.

Instead of information about the identity of a particular user, code identity security systems "authenticate" code itself by collecting information about the origin of code. For example, the .NET Framework security system collects (among other things) the following information about a piece of code:

• Site of origin

• URL of origin

• Authenticode signature (if present)

• Strong name signature (if present)

• Hash of the assembly

Information about the origin of code is referred to as evidence. For example, an assembly executed from the www.gotdotnet.com site would include site evidence pointing to the gotdotnet site, the specific URL of where it comes from, its hash, and, if applicable , its strong name signature value. Code-identity “based security systems, including CAS, authorize ”in other words, make grants of permissions to access protected resources ”based on evidence about the origin of code itself. The CAS system, for example, ships with a powerful, extensible security policy system that maps evidence to resource access permissions based on administrable policy settings. Authorization in code-identity “based security systems is always founded on information about a particular piece of code itself, not on the user context in which the code is executed. For example, CAS policy can be set such that all assemblies running from www.gotdotnet.com and signed by Microsoft get extra trust to access local resources ”the user context in which the code is run does not enter the authorization decision. Finally, code-identity “based security systems, such as CAS, enforce code-identity “based authorization decisions by strictly limiting the interplay and side effects between different pieces of code. For example, the CAS system relies heavily on the code isolation mechanism implemented in the CLR called Application domains. Application domains are similar to Windows processes in the world of the .NET Framework and, by isolating code running in one Application domain from code running in another, differences of security trust allotment cannot be circumvented. To summarize, code-identity “based security systems

• Authenticate code identity ” Information about the origin of a piece of code (such as the URL where it is run from) are collected and presented to the authorization layer.

• Authorize code, not users, to access resources ” All trust decisions to access protected resources are made for particular pieces of code, based on security settings evolving around information about the origin of code.

• Enforce the authorization decisions on particular pieces of code, not users ” The granularity of enforcement functions on the level of individual pieces of code (such as individual assemblies).

More specifically , the Code Access Security system shipping in the .NET Framework

• Authenticates assemblies ” By collecting evidence about the assembly, such as the assembly's URL or strong name

• Authorizes assemblies ” By granting assemblies a set of permissions to access protected resources (such as the file system or registry)

• Enforces authorization decisions ” By checking that all assemblies calling to a protected resource have the appropriate permission to access that resource, as well as enforces isolation between application domains

Much of the remainder of this book is about spelling out the details of CAS authentication, authorization, and enforcement mechanisms.

You may still wonder how this security paradigm answers the challenges brought up against user-identity “based security systems previously discussed. The main advantage of code-identity “based security systems is that it no longer treats all code running on behalf of the same user as equal. In fact, code-identity “based security systems allow for a potentially indefinite discrimination of different code identities and, thus, an indefinitely fine-grained access rights allotment scheme to different pieces of code. In code-identity “based security systems, such as CAS, code is the first class citizen around which the whole model evolves. By differentiating between different assemblies based on their evidence, the CAS system can be configured to answer all the specific scenarios for which user-identity “based security systems were found lacking.

• CAS policy can be configured to treat all assemblies coming from the intranet with less trust than the assemblies residing on the local machine. In fact, as you will see in Chapter 8, "Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy," and Chapter 18, "Administering Security Policy Using the .NET Framework Configuration Tool," default CAS policy is designed to do just that. This capability will allow an administrator to run a trusted managed application from his local hard drive, while executing an untrustworthy control from the intranet without fearing that the control may abuse his administrative privileges.

• Again, CAS policy can also be configured to treat all assemblies running from the Internet with less trust than the assemblies installed on the local machine. Default CAS policy is already structured this way. For example, this will allow a user to run an application from the local disk with access to her profile directory, while preventing any assembly from the Internet from accessing her personal files and data. Again, code-identity “based security systems allow for the execution of code with widely different levels of trust in the same user context.

• Because evidence, information about the origin of an assembly, is the type of information CAS policy is based on, it is possible to design a CAS policy configuration that grants assemblies from trusted publishers' permissions to access protected resources, while locking down access to the same resources to all other assemblies. For example, this allows administrators to prevent any assemblies from the Internet or intranet, except for assemblies signed by trusted publishers, from running. Assemblies executing in the same user context are treated with very different levels of trust in this case.

As could be seen, code-identity “based security systems can answer some of the shortcomings of user-identity “based security systems in a world where different applications or components may require different levels of trust, even if run under the same user context. You may now wonder exactly what the interplay between the two types of security paradigms should be. In particular, you may wonder whether code-identity “based security could not replace the less granular user-identity “based security paradigm.

for RuBoard