DIVYA KONERU

Topics CoveredIntroduction to runtime securityRole-Based SecurityCode-Access SecurityEvidenceSecurity Policy levelsPolicy resolutionPermissions

Introduction to Runtime Security

. Net Framework is a flexible general purpose computing platform designed to address the needs of commercial organizations , and support many different application models.

However, . Net places an emphasis on supporting the trend towards highly distributed systems , component-based applications , web-based server solutions , including XML Web services

Introduction to Runtime Security.Net Framework’s strong support for distributed

application models and its cross-platform capabilities means that software is more mobile , accessible, and integrated than before.

Although this provide functionality and productivity benefits , it also means that software consumers , producers , and service providers need to place a greater emphasis on software and system security

Introduction to Runtime SecurityCross-platform solutions cannot always rely on

the underlying operating system to provide the same security services on all platforms

The .NET runtime implements the following three features that provide platform-independent security services

Role-based securityCode-access security Isolated storage

Running Unverifiable and Native Code

Runtime security works because the CLR is a managed execution environment that goes to great lengths to ensure that the code it loads is type-safe .Code that is not type-safe is referred to as unverifiable code.

During execution ,the . Net runtime , class libraries and all required application assemblies are loaded to same operating system process . If type safety is not enforced , malicious code could manipulate the state of runtime’s security system.

Running Unverifiable and Native CodeAnother common risk to runtime security is the

use of native code .However once native code is running ,malicious

native code can delete important files or even change the .NET runtime’s security configuration files which are stored as XML.

There are situations when it is necessary to use both native and unverifiable code . However , the runtime restricts access to these capabilities using code-access security mechanism

Role-Based SecurityRole-Based security is a common security

model .When users wish to access a computer system . They must first prove their identity – a process known as authentication.

The system relies on the user’s authenticated identity when performing authorization-the process of determining what actions and resources a user has authority to access.

A person’s authority is expressed in terms of roles. A role is a logical categorization that grants members of the role specific permissions.

Role-Based SecurityIn .NET RBS , an identity represents the user on

whose behalf code is running . Normally this is currently logged-on Windows user but ,if your application authenticates users against an authority other than the Windows account system , then the identity may be different

A principle encapsulates an identity and the roles to which the identity belongs

Role-Based Security

If the identity represents a window user account ,the roles will identify the windows group to which the user belongs . Because a principle encapsulates both the identity and roles of a user

Code-Access Security

Traditionally code executes using the Identity , roles and permissions of user that runs it , but these days it is insufficient to base system security decisions solely on the permission granted to the user running an application

A highly trusted user cannot freely download and run an application from an untrusted source for fear of what the code may do to his system and other systems in the network

Code-Access Security

The .Net framework includes an important new feature known as code-access security (CAS),which provides fine-Grained control over the operations and resources to which managed code has access .with CAS , access is based on the identity of the code ,not user running it .some examples of operations protected by CAS

Creating , deleting ,and modifying files and directories

Reading from and writing to windows registryUsing sockets to accept initiate a network connectionCreating new application domains

Code-Access Security

The three key elements of code-access security are

Evidence : Prove to me who you are . CAS Policies are matched to your code based on various attributes (evidence) in your code.

Security policy : It provides mapping between evidence and permissions

Permissions : A task that your code is allowed to perform

Code-Access Security

When runtime loads an assembly , it inspects various characteristics of the assembly(evidence) to determine an identity for the code . Based on a configurable set of rules(security policy), the runtime uses the assembly’s evidence as input to a process named policy resolution. the result of policy resolution is a set of protected operations and resources to which the code within the assembly has access(permissions)

Window Security and CAS

CAS is effectively another layer of security that managed code must pass through before it can interact with protected system resources , such as hard disk and the windows registry

Window Security and CASThe important difference between CAS and

Windows security is that CAS bases security decisions on the identity of the code performing an action ,whereas Windows bases security decisions on the identity of the user on whose behalf the code is running

Evidence

The combined set of evidence establishes an identity for the assembly. When the runtime loads an assembly, it compares the assembly's identity with the rules defined in the security policy to determine the permissions to grant to the assembly, called the grant set.

The same assembly can have very different identities (and hence permissions) based on runtime evidence. If you run an assembly from an Internet site, its evidence will be different than if you first download the assembly to your hard disk and run it locally

EvidenceThere are two types of evidences:Host EvidenceAssembly Evidence

Host EvidenceThe host, in conjunction with the assembly loader component of the CLR, provides the host evidence for an assembly

Security Policy Security Policy is the set of configurable rules

that provide a mapping between evidence and permissions.

The runtime uses security policy to determine which code-access permissions to grant an assembly or application domain based on the set of evidence that the assembly or application domain presents-a process known as policy resolution

The security policy mechanism is Flexible and Extensible . no single set of security restrictions can meet everyone’s requirements

Security Policy Levels

.NET divides security policy in to four levels . The enterprise , machine , and user levels are configurable independently using administrative tools provided with the .NET Framework . As the application domains exist only at runtime ,it is not possible to configure them statically using tools .One can configure it programmatically

Security Policy LevelsThe runtime intersects the sets of permission

granted by each policy level to determine the final code-access permission set for the assembly or application domain

The purpose of enterprise policy is to provide a corporate- wide security policy that is enforced on all machines , but both the enterprise and machine policies are machine-specific

User policy is user-specific ; on a machine used by different people , each user will have his own user policy configuration

Security policy LevelsThe Trade-off for the division of security policy into

different levels is the complexity and the flexibility . but the flexibility it provides far outweighs the complexity ,especially in corporate environments . with multiple levels of security ,it is possible to delegate the task of security management

For , example the central IT or security department can use enterprise policy to enforce the minimum security standards of the Organization ,while giving departments , teams , or even individuals the autonomy to further restrict permissions to suit local needs with machine and user policy

Security Policy Level

Each policy level contains three key elementsCode GroupsNamed permission setsFully trusted assemblies

Code group

Each policy level consists of a set of a code groups organized in to tree structure . During policy resolution , the runtime traverses the tree of code groups in each policy level and compares the evidence presented by assembly or application domain with the membership condition of each code group . If the evidence meets the code group’s membership condition , then the runtime grants the permissions contained in the code group’s permission set

Code group

Fig : Membership Condition

Each code group contains following elements:

Membership condition : It defines the evidence that an assembly or application domain must have to qualify for membership to a code group

Permission set : It is the set of permissions to grant an assembly or application domain that qualifies for membership of the code group

Named Permission SetsAs the name suggests, named permission sets are simply groups of permissions to which you assign a name. Each policy level maintains its own set of named permission sets that are valid only within the scope of that policy level.

Fully trusted AssembliesEach policy level contains a list of fully trusted

assemblies .When the runtime loads any of these assemblies during policy resolution, it automatically assigns them full trust within that policy level.

Making an assembly fully trusted in one policy level does not mean that that assembly has full trust during program execution. The final set of permissions granted to the assembly is still calculated by intersecting the permission sets granted by each policy level.

Policy ResolutionWhen resolving policy for an assembly, the runtime

starts at the enterprise policy's root codegroup and checks the assembly's evidence against the code group's membership condition. If the evidence meets the membership condition, the runtime grants the permissions specified in the code group's permission set to the assembly.

The runtime then traverses the code group tree by comparing the assembly's evidence with each child code group of the current code group. At any stage, if the assembly does not qualify for membership of a code group, then the runtime does not grant the code group's permission set to the assembly, and policy resolution moves on to the next peer-level code group, ignoring the current code group's children.

Policy Resolution

Policy Resolution

Permissions

CAS Operation : security demand

Permissions

The runtime grants each of the application's assemblies a set of permissions at load time, which the runtime represents with a set of permission objects that it associated with the assemblies.

When an assembly's code calls a protected library member, the library uses a permission object to demand that the runtime ensure that the calling assembly has the equivalent permission. The runtime evaluates the permission objects associated with the assembly and confirms to the library whether the assembly has the specified permission.

Granting Permission

Code-access permissions

Code-access permission continued…

Code-access permission continued….

Identity Permissions

Thank You!