1. .Net Security and performance
DIVYA KONERU

2. Topics Covered Introduction to runtime security Role-Based Security
Code-Access Security
Evidence
Security Policy levels
Policy resolution
Permissions

3. 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

4. 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

5. Introduction to Runtime Security
Cross-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 security
Code-access security
Isolated storage

6. 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.

7. Running Unverifiable and Native Code
Another 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

8. Role-Based Security
Role-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.

9. Role-Based Security
In .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

10. 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

11. 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

12. 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 registry
Using sockets to accept initiate a network connection
Creating new application domains

13. 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

14. 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)

15. 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

16. Window Security and CAS
The 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

17. 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

18. Evidence There are two types of evidences: Host Evidence
Assembly Evidence

19. Host Evidence
The host, in conjunction with the assembly loader component of the CLR, provides the host evidence for an assembly

20. 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

21. 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

22. Security Policy Levels
The 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

23. Security policy Levels
The 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

24. Security Policy Level Each policy level contains three key elements
Code Groups
Named permission sets
Fully trusted assemblies

25. 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

26. 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

27. Named Permission Sets
As 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.

28. Fully trusted Assemblies
Each 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.

29. Policy Resolution
When 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.

30. Policy Resolution

31. Policy Resolution

32. Permissions
CAS Operation : security demand

33. 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.

34. Granting Permission

35. Code-access permissions

36. Code-access permission continued…

37. Code-access permission continued….

38. Identity Permissions

39. Thank You!